In 'sh' how to put the result of a string comparison into a variable? - string

In basic 'shell', how do I put the result of a string comparison into a boolean variable?
Consider:
isweekday() {
w=$(date +%w)
if [[ $w == "0" ]] || [[ $w == "6" ]]; then
false
else
true
fi
}
One can debate whether it would be clearer or not, but is there a way to assign the result of the 'if' expression to a boolean variable, e.g.
isweekday() {
w=$(date +%w)
wd=<boolean result of [[ $w == "0" ]] || [[ $w == "6" ]]>
return $wd
}
After some experimentation, I got closer to what I want but it still isn't what I'm after:
isweekday() {
w=$(date +%w)
[[ $w == "0" ]] || [[ $w == "6" ]]
}
This works and does not require the conditional, but it looks wrong, however if you do:
if isweekday; then
echo 'weekday'
fi
you will get the right result. This seems to be because the exit code of 'true' is 0 and the exit code of 'false' is 1 (not quite sure why that is...)

There are no boolean variables. All shell variables are strings (though there are limited facilities for interpreting them as integer numbers for basic comparisons etc and basic arithmetic).
The exit code 0 is reserved for success; all other exit codes (up to the maximum 255) signify an error (though some nonstandard tools use this facility to communicate non-error results by way of convention; the caller is then assumed to understand and agree on this ad-hoc use of the exit code).
Perhaps then the simplest answer to what you appear to be asking is to save the exit code. It is exposed in the variable $?. But very often, you should not need to explicitly examine its value; indeed, your final isweekday code looks by far the most idiomatic and natural, and returns this code from [[ implicitly.
I don't understand why you think your final code "looks wrong"; this is precisely how you would use a function in a conditional.
However, in some sense, a case statement would look less cluttered here (but this syntax is somewhat jarring at first for other reasons, until you get used to it).
is_weekday () {
case $(date +%w) in
0 | 6) return 1;;
esac
return 0
}
This is portable to POSIX sh, unlike the Bash-only [[...]] syntax you were using. Perhaps see also Difference between sh and bash

The standard approach in Shell is to use the exit code of a command as the true/false value where zero indicates true and non-zero false. Also, I would instead define a function which tests if it's weekend today since that is the exception so to speak. It's also a good idea to define w as a local variable and to quote all variables which could in the general case contain a space or be undefined, something which can lead to a syntax error after variable expansion. Here is my suggestion:
IsWeekend()
{
local w="$(date +%w)"
[ "$w" = 0 ] || [ "$w" = 6 ]
}

Related

Why do two empty strings compare as not equal?

my#comp:~/wtfdir$ cat wtf.sh
str1=$(echo "")
str2=$(echo "")
if [ $str1 != $str2 ]; then
echo "WTF?!?!"
fi
my#comp:~/wtfdir$ ./wtf.sh
WTF?!?!
my#comp:~/wtfdir$
WTF is going on here?!
How I wrote the above code: Googling "bash compare strings" brought me to this website which says:
You can check the equality and inequality of two strings in bash by using if statement. “==” is used to check equality and “!=” is used to check inequality of the strings.
Yet I'm getting the above?
What am I not understanding? What am I doing wrong?
You aren't running a comparison at all, because you aren't using quotes where they're mandatory. See the warning from http://shellcheck.net/ about unquoted expansions at SC2086.
If both string are empty, then:
[ $str1 != $str2 ]
...evaluates to...
[ != ]
...which is a test for whether the string != is nonempty, which is true. Change your code to:
[ "$str1" != "$str2" ]
...and the exact values of those strings will actually be passed through to the [ command.
Another alternative is using [[; as described in BashFAQ #31 and the conditional expression page on the bash-hackers' wiki, this is extended shell syntax (in ksh, bash, and other common shells extending the POSIX sh standard) which suppresses the string-splitting behavior that's tripping you up:
[[ $str1 != "$str2" ]]
...requires quotes only on the right-hand side, and even those aren't needed for the empty-string case, but to prevent that right-hand side from being treated as a glob (causing the comparison to always reflect a match if str2='*').

Having trouble with simple Bash if/elif/else statement

I'm writing bash scripts that need to work both on Linux and on Mac.
I'm writing a function that will return a directory path depending on which environment I'm in.
Here is the pseudo code:
If I'm on a Mac OS X machine, I need my function to return the path:
/usr/local/share/
Else if I'm on a Linux machine, I need my function to return the path:
/home/share/
Else, you are neither on a Linux or a Mac...sorry.
I'm very new to Bash, so I apologize in advance for the really simple question.
Below is the function I have written. Whether I'm on a Mac or Linux, it always returns
/usr/local/share/
Please take a look and enlighten me with the subtleties of Bash.
function get_path(){
os_type=`uname`
if [ $os_type=="Darwin" ]; then
path="/usr/local/share/"
elif [ $os_type=="Linux" ]; then
path="/home/share/"
else
echo "${os_type} is not supported"
exit 1
fi
echo $path
}
You need spaces around the operator in a test command: [ $os_type == "Darwin" ] instead of [ $os_type=="Darwin" ]. Actually, you should also use = instead of == (the double-equal is a bashism, and will not work in all shells). Also, the function keyword is also nonstandard, you should leave it off. Also, you should double-quote variable references (like "$os_type") just in case they contain spaces or any other funny characters. Finally, echoing an error message ("...not supported") to standard output may confuse whatever's calling the function, because it'll appear where it expected to find a path; redirect it to standard error (>&2) instead. Here's what I get with these cleaned up:
get_path(){
os_type=`uname`
if [ "$os_type" = "Darwin" ]; then
path="/usr/local/share/"
elif [ "$os_type" = "Linux" ]; then
path="/home/share/"
else
echo "${os_type} is not supported" >&2
exit 1
fi
echo "$path"
}
EDIT: My explanation of the difference between assignments and comparisons got too long for a comment, so I'm adding it here. In many languages, there's a standard expression syntax that'll be the same when it's used independently vs. in test. For example, in C a = b does the same thing whether it's alone on a line, or in a context like if ( a = b ). The shell isn't like that -- its syntax and semantics vary wildly depending on the exact context, and it's the context (not the number of equal signs) that determines the meaning. Here are some examples:
a=b by itself is an assignment
a = b by itself will run a as a command, and pass it the arguments "=" and "b".
[ a = b ] runs the [ command (which is a synonym for the test command) with the arguments "a", "=", "b", and "]" -- it ignores the "]", and parses the others as a comparison expression.
[ a=b ] also runs the [ (test) command, but this time after removing the "]" it only sees a single argument, "a=b" -- and when test is given a single argument it returns true if the argument isn't blank, which this one isn't.
bash's builtin version of [ (test) accepts == as a synonym for =, but not all other versions do.
BTW, just to make things more complicated bash also has [[ ]] expressions (like test, but cleaner and more powerful) and (( )) expressions (which are totally different from everything else), and even ( ) (which runs its contents as a command, but in a subshell).
You need to understand what [ means. Originally, this was a synonym for the /bin/test command. These are identical:
if test -z "$foo"
then
echo "String '$foo' is null."
fi
if [ -z "$foo" ]
then
echo "String '$foo' is null."
fi
Now, you can see why spaces are needed for all of the parameters. These are parameters and not merely boolean expressions. In fact, the test manpage is a great place to learn about the various tests. (Note: The test and [ are built in commands to the BASH shell.)
if [ $os_type=="Darwin" ]
then
This should be three parameters:
"$os_type"
= and not ==
"Darwin"
if [ "$os_type" = "Darwin" ] # Three parameters to the [ command
then
If you use single square brackets, you should be in the habit to surround your parameters with quotation marks. Otherwise, you will run into trouble:
foo="The value of FOO"
bar="The value of BAR"
if [ $foo != $bar ] #This won't work
then
...
In the above, the shell will interpolate $foo and $bar with their values before evaluating the expressions. You'll get:
if [ The value of FOO != The value of BAR ]
The [ will look at this and realize that neither The or value are correct parameters, and will complain. Using quotes will prevent this:
if [ "$foo" != "$bar" ] #This will work
then
This becomes:
if [ "The value of FOO" != "The value of BAR" ]
This is why it's highly recommended that you use double square brackets for your tests: [[ ... ]]. The test looks at the parameters before the shell interpolates them:
if [[ $foo = $bar ]] #This will work even without quotation marks
Also, the [[ ... ]] allows for pattern matching:
if [[ $os_type = D* ]] # Single equals is supported
then
path="/usr/local/share/"
elif [[ $os_type == L* ]] # Double equals is also supported
then
path="/home/share/"
else
echo "${os_type} is not supported"
exit 1
fi
This way, if the string is Darwin32 or Darwin64, the if statement still functions. Again, notice that there has to be white spaces around everything because these are parameters to a command (actually, not anymore, but that's the way the shell parses them).
Adding spaces between the arguments for the conditionals fixed the problem.
This works
function get_path(){
os_type=`uname`
if [ $os_type == "Darwin" ]; then
path="/usr/local/share/"
elif [ $os_type == "Linux" ]; then
path="/home/share/"
else
echo "${os_type} is not supported"
exit 1
fi
echo $path
}

Check and modify format of variable in expect script

I am trying to verify that the format of a variable is a number and is at least 10 digits long with leading zeros, inside of an expect script.
In a bash script it would look something like this:
[[ "$var" != +([0-9]) ]] && echo "bad input" && exit
while [[ $(echo -n ${var} | wc -c) -lt 10 ]] ; do var="0${var}" ; done
For the following input:
16
I am trying to achieve the following output:
0000000016
The simplest way to check whether a variable has just digits is to use a regular expression. Expect's regular expressions are entirely up to the task:
if {![regexp {^\d+$} $var]} {
puts "bad input"
exit
}
Padding with zeroes is best done by formatting the value; if you know C's printf(), you'll recognize the format:
set var [format "%010d" $var]
Expect is actually just an extension of TCL, so you can use any facility that TCL provides. TCL is an unusual language, but it's not hard to do what you want.
# Set a test string.
set testvar 1234567890
# Store the match (if any) in matchvar.
regexp {\d{10,}} $testvar matchvar
puts $matchvar
# Test that matchvar holds an integer.
string is integer $matchvar
The string is command is relatively new, so you might have to rely on the return value of regexp if your TCL interpreter doesn't support it.

ksh function return value in parentheses

In the following very simple ksh script example, I need to ask if func1 results equal to 4 ,
This is what I did in the example but this script does not print the "function result = 4" as I expected it to.
What do I need to change in the [[......]] in order to print the "function result = 4"
Remark - func1 must be in the [[.....]]
#!/bin/ksh
func1()
{
return 4
}
[[ ` func1 ` = ` echo $? ` ]] && print "function result = 4"
You need
#!/bin/ksh
func1()
{
print -- 4
}
[[ $(func1) = 4 ]] && print "function result = 4"
OR
#!/bin/ksh
func1()
{
return 4
}
func1 ; [[ $? == 4 ]] && print "function result = 4"
There are several issues in the code that you present, so let me try to explain (You're making it more complicated than it need be).
No. 1 is your use of back-ticks for command substitution, these have been deprecated in the ksh language since ~ 1995! Use $( ... cmd ) for modern cmd-substitution. We often see backticks listed as a nod to portability, but only scripts written for systems where the Bourne shell is the only shell available require the use of backticks. (well, I don't know about dash or ash, so maybe those too).
No 2. is that $? gets set after ever function or command or pipeline is executed and is the return code of that last command. It is a value between 0-255. When you have code like cmd ; rc=$? ; echo $? ; you're now echoing the status of the assignment of rc=$? (which will almost always be 0), AND that is why you will see experienced scriptors save the value of $? before doing anything else with it.
Recall that command-substitution uses what ever is the output of the $( ... cmd ...) or backtics enclosed command while return sets the value of $? (until the very next command execution resets that value).
I hope this helps.
Function does return 4. The operator `` (backticks) ignores the result value, and returns the function's stdout instead (in your case an empty string, since func1 did not print anything to stdout).
And
`echo $?`
is just over-complicated way of saying
$?

Compare integer in bash, unary operator expected

The following code gives
[: -ge: unary operator expected
when
i=0
if [ $i -ge 2 ]
then
#some code
fi
why?
Your problem arises from the fact that $i has a blank value when your statement fails. Always quote your variables when performing comparisons if there is the slightest chance that one of them may be empty, e.g.:
if [ "$i" -ge 2 ] ; then
...
fi
This is because of how the shell treats variables. Assume the original example,
if [ $i -ge 2 ] ; then ...
The first thing that the shell does when executing that particular line of code is substitute the value of $i, just like your favorite editor's search & replace function would. So assume that $i is empty or, even more illustrative, assume that $i is a bunch of spaces! The shell will replace $i as follows:
if [ -ge 2 ] ; then ...
Now that variable substitutions are done, the shell proceeds with the comparison and.... fails because it cannot see anything intelligible to the left of -gt. However, quoting $i:
if [ "$i" -ge 2 ] ; then ...
becomes:
if [ " " -ge 2 ] ; then ...
The shell now sees the double-quotes, and knows that you are actually comparing four blanks to 2 and will skip the if.
You also have the option of specifying a default value for $i if $i is blank, as follows:
if [ "${i:-0}" -ge 2 ] ; then ...
This will substitute the value 0 instead of $i is $i is undefined. I still maintain the quotes because, again, if $i is a bunch of blanks then it does not count as undefined, it will not be replaced with 0, and you will run into the problem once again.
Please read this when you have the time. The shell is treated like a black box by many, but it operates with very few and very simple rules - once you are aware of what those rules are (one of them being how variables work in the shell, as explained above) the shell will have no more secrets for you.
Judging from the error message the value of i was the empty string when you executed it, not 0.
I need to add my 5 cents. I see everybody use [ or [[, but it worth to mention that they are not part of if syntax.
For arithmetic comparisons, use ((...)) instead.
((...)) is an arithmetic command, which returns an exit status of 0 if
the expression is nonzero, or 1 if the expression is zero. Also used
as a synonym for "let", if side effects (assignments) are needed.
See: ArithmeticExpression
Your piece of script works just great. Are you sure you are not assigning anything else before the if to "i"?
A common mistake is also not to leave a space after and before the square brackets.

Resources