How to avoid "command not found" in a bash parameter expansion? - bash

I wrote the following bash script:
${MY_FLAG:=true}
${LOG_FILE:="something.log"}
I am trying to assign true to MY_FLAG and the string "something.log" to LOG_FILE. I use parameter expansions because I want to set these variables only if they were not set already.
The problem is that MY_FILE becomes true but LOG_FILE throws an error:
script.sh: line 2: something.log: command not found
I could not find a way to assign the string as is, I tried with different options, simple quotes, and echoing it but nothing did the trick for me.

The parameters will always expand to a value, so you'll have to use them in a context where such an argument is ignored. Conveniently, : aka true does this:
: "${LOG_FILE:="something.log"}"
It only happens to work for your ${MY_FLAG:=true} because true (as discussed) is a valid command. If you run the script with MY_FLAG=date ./yourscript then you'll see that it actually runs date instead of just assigning a default.

Related

How does "FOO= myprogram" in bash make "if(getent("FOO"))" return true in C?

I recently ran into a C program that makes use of an environmental variable as a flag to change the behavior of a certain part of the program:
if (getenv("FOO")) do_this_if_foo();
You'd then request the program by prepending the environment variable, but without actually setting it to anything:
FOO= mycommand myargs
Note that the intention of this was to trigger the flag - if you didn't want the added operation, you just wouldn't include the FOO=. However, I've never seen an environment variable set like this before. Every example I can find of prepended variables sets a value, FOO=bar mycommand myargs, rather than leaving it empty like that.
What exactly is happening here, that allows this flag to work without being set? And are there potential issues with implementing environmental variables like this?
The bash manual says:
A variable may be assigned to by a statement of the form
name=[value]
If value is not given, the variable is assigned the null string.
Note that "null" (in the sense of e.g. JavaScript null) is not a thing in the shell. When the bash manual says "null string", it means an empty string (i.e. a string whose length is zero).
Also:
When a simple command is executed, the shell performs the following expansions, assignments, and redirections, from left to right.
[...]
If no command name results, the variable assignments affect the current shell environment. Otherwise, the variables are added to the environment of the executed command and do not affect the current shell environment.
So all FOO= mycommand does is set the environment variable FOO to the empty string while executing mycommand. This satisfies if (getenv("FOO")) because it only checks for the presence of the variable, not whether it has a (non-empty) value.
Of course, any other value would work as well: FOO=1 mycommand, FOO=asdf mycommand, etc.
FOO= is just setting the variable to null (to be precise it's setting the variable to a zero-byte string, which thus returns a pointer to a NUL terminator - thanks #CharlesDuffy). Given the code you posted it could be FOO='bananas'and produce the same behavior. It's very odd to write code that way though. The common reason to set a variable on the command line is to pass a value for that variable into the script, e.g. to set debugging or logging level flags is extremely common, e.g. (pseudocode):
debug=1 logLevel=3 myscript
myscript() {
if (debug == 1) {
if (loglevel > 0) {
printf "Entering myscript()\n" >> log
if (logLevel > 1) {
printf "Arguments: %s\n" "$*" >> log
}
}
}
do_stuff()
}
Having just a "variable exists" test is a bit harder to work with because then you have to specifically unset the variable to clear the flag instead of just setting FOO=1 when you want to do something and otherwise your script doesn't care when FOO is null or 0 or unset or anything else.

how to keep nested BASH parameter untokenized

Consider this trite BASH script:
g1="f 2.txt"
g2="f1.txt $g1"
cp $g2
It fails because I passed three parameters to the cp command. How do I escape the $g1 call to make it pass just two on the final line (er, make it work without passing two variables on line three)? I tried putting quotes around it with no success; it then proceeds to pass the quotes as part of the parameter, which is doubly weird.
In my real scenario I have some optional parameters that themselves take parameters. I had wanted to parse them all out at the top of the script and leave their final parsed values blank if they weren't passed in.
You can do it using shell arrays:
g1="f 2.txt"
g2=("f1.txt" "$g1")
cp "${g2[#]}"

How to achieve the variable value declared in two level

I have a Unix variable like below:
emp_tbl=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
Now I have created another variable like below:
tablename=emp_tbl
Now I want to see the value 1,2,3,... using $($tablename) but I am getting error in it:
~$>emp_tbl=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
~$>tablename=emp_tbl
~$>echo $($tablename)
-bash: emp_tbl: command not found
You need indirection:
echo ${!tablename}
Read the documentation on shell parameter expansion yet again (reminder to self: do thou likewise).
Your attempt using $($tablename) fails because the $(...) notation is command substitution, and the value in $tablename is interpreted as the command name and the command with the name emp_tbl could not be found.

Expanding variables before bash call/exec

I know the basics of Bash but often miss the nuance and I'm having a problem using it to achieve what I had hoped would be a rather simple problem:
If I have the following in a bash script, which works exactly as I'd want it to:
cbType=`echo $configuration | jsawk -a 'return _.where(this,{name: "reference_data"})'`
It takes $configuration -- which is a JSON string -- and identifies the array element where name is "reference_data" and returns that object/hash definition only. Please note that this does use the very handy jsawk utility but it has been designed to be exhibit good command-line behaviour.
The problem is that when I remove the hard-coded "reference-data" with a variable it seems to not be able to reference the scope of the variable. So for instance, ...
myVar="\"reference_data\""
cbType=`echo $configuration | jsawk -a 'return _.where(this,{name: $myVar})'`
Does not work and instead returns a jsawk error of:
jsawk: js error: ReferenceError: $myVar is not defined
Is there anything I can do to enforce that first the variable is expanded, and then the command string is executed?
Declared variables won't be expanded if it's not within double quotes. So put your code inside double quotes instead of single quotes.
myVar="\"reference_data\""
cbType=$(echo "$configuration" | jsawk -a "return _.where(this,{name: $myVar})")

Bash test with no options appears to work, but why?

I want to pass options to my bash script. If the option "GUI" is set, zenity should be used for input and output instead of the console. Currently I'm passing the option as an environment variable like this:
GUI=1 ./my_bash_script.sh
Then I found out that I could test for the length of the variable like this:
if [ -n "$GUI" ]; then
But then, quite randomly, I discovered that just testing the string with no options also appears to work as expected:
if [ "$GUI" ]; then
I've read the manual entry for test but I can't see any explanation for what happens if you just pass a string without any arguments. I'm guessing that if it receives an empty string it returns true, and otherwise it returns false? Is that the case?
You're correct. From the test(1) man page:
-n STRING
the length of STRING is nonzero
STRING equivalent to -n STRING

Resources