Testing Conditions with an 'x' Attached?

Horizon_Brave · 2016-01-02 22:07:03

Hey everyone, I was going over some scripts, in particular the startx script. I was following along with JohnRaff's guide to the startx script found here:
Startx

Anyway, some of the test conditionals like :

whoseargs="client"
while [ x"$1" != x ]; do

as well as:

if [ x"$client" = x ]; then
    client=$defaultclient

Now JohnRaff briefly explains, by saying

John Raff wrote:

It's a safety thing for some older shells which would go weird if one of the items was empty. [ x$var = x ] just means $var is empty.

But I'm not sure what is meant by this. If I do an:

echo $DISPLAY
I get :0

When I do
echo x$DISPLAY

it just, as predicted concatenates the x letter front of the :0

So what is the point of this? He says this is more for older shells. Is this tactic soemthing that should be done in good practice whenever you test for a variable?

Thanks guys... I have an inkling as to what's going on, but just want to confirm it... I'm assuming if the variable $DISPLAY returned, literally nothing, soemthing bad would happen... So we stick x there to test against?

But if that's the case, why not use the

if [[ -z  $DISPLAY ]]

damo · 2016-01-02 22:25:19

Horizon_Brave wrote:

But if that's the case, why not use the
if [[ -z  $DISPLAY ]] 

The double `[[...]]` ("extended test command") syntax was introduced in Bash v2.02

Head_on_a_Stick · 2016-01-02 22:26:27

Horizon_Brave wrote:

why not use the
if [[ -z  $DISPLAY ]] 

I think it's because the [[...]] conditional (from the Korn shell originally and adopted by bash) doesn't work Debian's version of /bin/sh (dash)

johnraff · 2016-01-03 04:36:34

^right.

As I said in the old thread, [ x$v = x ] just means $v is empty. Nowadays there are several more elegant ways of testing for empty or unset variables, but scripts that want to run in as many environments as possible sometimes have to resort to this kind of clumsy stuff.

ohnonot · 2016-01-03 09:50:02

i also like to use that "x" version.
there's another reason, which also applies to newer shells:
sometimes, the logic of the script simply needs to know whether the var contains useful data.
so a case where the var is undefined is equal to a case where the var contains the "empty string".
however, e.g. bash makes a distinction between a var being undefined and a var being empty.
with [[ "x$var" == "x" ]] you simply roll over that.

Horizon_Brave · 2016-01-03 19:50:02

ohnonot wrote:

i also like to use that "x" version.
there's another reason, which also applies to newer shells:
sometimes, the logic of the script simply needs to know whether the var contains useful data.
so a case where the var is undefined is equal to a case where the var contains the "empty string".
however, e.g. bash makes a distinction between a var being undefined and a var being empty.
with [[ "x$var" == "x" ]] you simply roll over that.

Oh wow, I didn't even think about that...the difference between "empty" and literally not defined...

johnraff wrote:

^right.
As I said in the old thread, [ x$v = x ] just means $v is empty. Nowadays there are several more elegant ways of testing for empty or unset variables, but scripts that want to run in as many environments as possible sometimes have to resort to this kind of clumsy stuff.

Thanks for the clarification.

And a question for everyone the x variable is obviously arbitrary right? I could use y or k or anything right?

johnraff · 2016-01-04 03:29:50

Yes, the x could be anything.

More on testing unset vs empty variables:
http://serverfault.com/questions/7503/h … e-is-empty
http://stackoverflow.com/questions/1226 … e-to-empty

xaos52 · 2016-01-04 13:00:08

@nobody
This is not generally agreed upon, see

Head_on_a_Stick · 2016-01-04 13:25:01

I like this one:

http://mywiki.wooledge.org/BashGuide

xaos52 · 2016-01-04 13:33:31

So do I.
Greg Wooledge is a regular poster in both the bash-users and bash-bugs mailing lists, which in themselves are (searchable) treasure troves.

Horizon_Brave · 2016-01-04 16:32:15

nobody wrote:

Advanced Bash Scripting Guide. Required reading. Answers all questions, possibly by inference.

xaos52 wrote:

@nobody
This is not generally agreed upon, see

Yea I was just about to ask actually, there seems to be some discontent about the complete accuracy of TLDP. Even I've seen some conflicting information..

But stuff like this:

Sorry to say it, but the "advanced" bash guide is the single largest source of misinformation
about bash out there. It's the reason you see so many people try to parse ls, or read a file line
by line with 'for foo in $(cat file)', or use unquoted expansions. The beginners guide you linked
to first actually has syntax errors in it, let alone the logic issues everywhere.

...Makes me worry. One of the downfalls to have such open source software.

But thanks guys, at the very least it points me in the right direction for a lot of the stuff.

Last edited by Horizon_Brave (2016-01-04 16:39:04)

tknomanzr · 2016-01-04 20:39:45

Some of that stuff has existed since 2000 or so and has never received an update. I am not saying the Bash Scripting Guide in particular but I seem to remember a lot of that documentation existing on a Redhat 6.0 system.

#1 2016-01-02 22:07:03

Testing Conditions with an 'x' Attached?

#2 2016-01-02 22:25:19

Re: Testing Conditions with an 'x' Attached?

#3 2016-01-02 22:26:27

Re: Testing Conditions with an 'x' Attached?

#4 2016-01-03 04:36:34

Re: Testing Conditions with an 'x' Attached?

#5 2016-01-03 09:50:02

Re: Testing Conditions with an 'x' Attached?

#6 2016-01-03 19:50:02

Re: Testing Conditions with an 'x' Attached?

#7 2016-01-04 03:29:50

Re: Testing Conditions with an 'x' Attached?

#8 2016-01-04 13:00:08

Re: Testing Conditions with an 'x' Attached?

#9 2016-01-04 13:25:01

Re: Testing Conditions with an 'x' Attached?

#10 2016-01-04 13:33:31

Re: Testing Conditions with an 'x' Attached?

#11 2016-01-04 16:32:15

Re: Testing Conditions with an 'x' Attached?

#12 2016-01-04 20:39:45

Re: Testing Conditions with an 'x' Attached?

Board footer