You are not logged in.
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
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 ]]
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
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
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
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)
Offline
^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.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
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.
Offline
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...
^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?
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
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
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
@nobody
This is not generally agreed upon, see
Offline
Offline
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.
Offline
Advanced Bash Scripting Guide. Required reading. Answers all questions, possibly by inference.
@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)
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
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.
Offline