#!/usr/bin/env bash
if [[ $# -eq '0' ]]
then
var=command
if [[ ${var} -eq '0' ]]
then
do something
else
do something else
fi
fi
if [[ $# -eq '1' ]]
usage;
fi
if [[ $# -eq '2' ]]
if [[ "$1" != "-r" ]]
then
usage;
fi
if [[ "$2" =~ some_pattern ]]
then
do something
else
echo "Pattern is in an improper format. Please enter it as: correct_pattern, and try again"
exit 1
fi
usage="Usage: meta_script.sh -r correct_pattern
-r for reset is used to manually pass a parameter instead of using the default"
exit 1
fi
When I run this script, this is the error I get:
./meta_script.sh: line 31: syntax error near unexpected token `fi'
./meta_script.sh: line 31: `fi'
In the first if statement where I'm checking if the number of parameters are equal to 1, I had put a then, but I got the same error as above, except with then instead of fi. It's almost as if no matter what I put and where, I get these errors and when I remove them to try and fix it, I get another bunch of similar errors. Please help me correct this script. Thanks!
With regard to the segment:
if [[ $# -eq '2' ]]
if [[ "$1" != "-r" ]]
then
you are missing the then for the first if statement. Putting that in should get you past that error:
if [[ $# -eq 2 ]] ; then
if [[ "$1" != "-r" ]] ; then
You'll see I've put the then on the same line since it's a good habit to get into, realising that if and then always go together (same as while and do). It also allows you to see more lines of "useful" code on any given terminal :-)
I've also gotten rid of the useless quotes around 2 since $# always returns a numeric value. I'd advise sticking to using quotes just for strings.
Related
I'm just learning terminal commands, I'm trying to create my own command, but I have the following problem
./myFile: line 10: syntax error in conditional expression
./myFile: line 11: syntax error near `then'
./myFile: line 11: ` then'
there is my code
#!/bin/bash
echo "please enter name of the folder"
read NAME1
if [[ $NAME1 ]]
then
echo "enter first number"
read NUM1
if [[ $NUM1 ]] && [[ $NUM1 -ge 0]]
then
echo "enter last number"
read NUM2
if [[ $NUM2 ]] && [[ $NUM2 -gt $NUM ]]
then
mkdir $NAME1{$NUM1..$NUM2}
else
echo"please enter last number to continue"
fi
else
echo "please enter first number to continue"
fi
else
echo "please enter name of the folder to continue"
fi
Firstly, the expression [[ $NAME1 ]] is not valid, or at least, does not do what you think it does. I believe you are trying to determine if the user actually typed in a string. To do this, you should either test for a non-empty string ([[ -n ${NAME1} ]]) or test for a string length greater than zero ([[ ${#NAME1} -gt 0 ]]). The same applies when you are testing $NUM1 and $NUM2.
Secondly, when dealing with user input, you should take care to avoid testing empty strings. This is best achieved by quoting your variables. For example: [[ "${NUM1}" -gt 0 ]].
Thirdly, spaces are important in tests. always leave a space after the [[ and before the ]].
In addition, $NUM (line 15) is not declared, so will evaluate to the empty string. This should be set somewhere earlier in the script.
There are many other areas in which this script could be improved (e.g. checking for numerical input, checking for valid folder names, etc. But the above changes should get you past the immediate errors.
I am trying to check:
if $file is a binary, and the $file is not an image file then do something.
if [[ "$(file --dereference --mime "$FILE")" =~ binary ]] && [[ "$FILE" != \.jpg$|\.jpeg$|\.png$ ]]; then
echo "$1 is a binary file"
exit 0
fi
The error is a syntax error in conditional expression: unexpected token
I guess I am probably overlooking something simple. I have googled quite a bit but cannot get a working statement. Any tips are greatly appreciated.
You seem to trying to do a negate match on the second [[. You can do it by putting ! before a match =~
Here is an example that may help you:
[[ ! 'foo.png' =~ \.(jpe?g|png)$ ]] && echo not a image
I am puzzled about the verbose of quoting in the script. Take an example from the instruction I followed:
min_val=1
max_val=100
int=50
if [[ "$int" =~ ^-?[0-9]+$ ]]; then
if [[ "$int" -ge "$min_val" && "$int" -le "$max_val" ]]; then
echo "$int is within $min_val to $max_val."
else
echo "$int is out of range."
fi
else
echo "int is not an integer." >&2
exit 1
fi
Run it and come by:
$ bash test_integer3.sh
50 is within 1 to 100.
When I removed all the quoting in testing:
if [[ $int =~ ^-?[0-9]+$ ]]; then
if [[ $int -ge $min_val && $int -le $max_val ]]; then
echo "$int is within $min_val to $max_val."
else
echo "$int is out of range."
fi
else
echo "int is not an integer." >&2
exit 1
fi
It's still working properly.
$ bash test_integer3.sh
50 is within 1 to 100.
Why should live with the habit of writing redundant quoting?
The real problem comes when you start to use [ command over [[ in your scripts. [[ is bash's improvement to the [ command. It has several enhancements that make it a better choice to write scripts targeting bash.
One such improvement would be that you no longer have to quote variables because [[ handles empty strings and strings with white-space more intuitively. For example consider your script written with [ for the un-quoted case and for discussions sake, one of your variables is empty
#!/usr/bin/env bash
min_val=
max_val=
int=50
if [[ $int =~ ^-?[0-9]+$ ]]; then
if [ $int -ge $min_val -a $int -le $max_val ]; then
echo "$int is within $min_val to $max_val."
else
echo "$int is out of range."
fi
else
echo "int is not an integer." >&2
exit 1
fi
One thing to note is I've re-written the combined conditional using the -a syntax since [ does not support && operator within but could be combined using && as [ $int -ge $min_val ] && [ $int -le $max_val ]
You would see things going bad and seeing errors as below which means that one of the conditionals involving -le is gone wrong on seeing an empty string.
1_script.sh: line 7: [: -a: integer expression expected
50 is out of range.
whereas with same code for undefined variables and replacing the expression to use [[ would gracefully handle the empty strings to produce just an incorrect result as
50 is out of range.
So to sum it up, from the many advantages over using [[, the particular advantage on your case is to handle variables if there could be empty strings in your conditionals.
Quoting is used to to stop the word splitting. In the case above it is not necessary but consider a case like this: you have a directory and having theses files file1.txt, file2.txt, old.txt and file1 old.txt.
If you wish to remove the file file1 old.txt and run the command
rm file1 old.txt
then it will remove the file old.txt instead of what you expected.
In your piece of code you don't need quotes as you discovered. However, using quotes is considered "good practice" because unexpected things can happen without quotes. For example if you run the code with int equal to say "foo bar" you might get some strange results without quotes.
It is like the double and triple equals in JavaScript. You could probably get away with only double equals but some unexpected results might occur.
I am very new to Bash Scripting and I have a question regarding my CheckOurCodingRules.sh script:
I want to search for every 'hPar,' in a textfile and if found it should be checked if there is a also a 'const' in the same row.
Thats what I got so far but there is something wrong here:
while read line
do
if [[ $line == *hPar\,* ]] && [[ $line == *const\*]];then
DOCUMENTATION_TEST_A=1
else
echo DOCUMENTATION_TEST_A=0
fi
done < $INPUT_FILE
if [[DOCUMENTATION_TEST_A=0]];then
echo "error: Rule1: No const before hpar"
fi
There are a couple of issues with your script, see the code below which works for me:
DOCUMENTATION_TEST_A=0 # initial value
while read line
do
# spaces between conditional and brackets, no backslashes
if [[ $line == *hPar,* ]] && [[ $line == *const* ]]
then
DOCUMENTATION_TEST_A=1
break # optional, no need to scan the rest of the file
fi
done < $INPUT_FILE
# spaces and $, -eq is used for numerical comparisons
if [[ $DOCUMENTATION_TEST_A -eq 0 ]];
then
echo "error: Rule1: No const before hpar"
fi
A cleaner solution would be to use grep:
if ! grep "hPar," $INPUT_FILE | grep "const" >/dev/null
then
echo "error: Rule1: No const before hpar"
fi
I'm trying to write a short bash script that optionally accepts arguments from the command line, or prompts for their input
if [ [ -z "$message" ] && [ -z "$predefined" ] ] ; then
read -p "Enter message [$defaultMessage]: " message
message=${message:-$defaultMessage}
else
if [ -n "$predefined" ]; then
if [ -f $base/$environment/vle/data/$predefined.txt ]; then
echo Predefined message file $predefined.txt does not exist
exit 1
fi
fi
fi
If neither message nor predefined has been passed in as command line arguments, then the code should prompt for a value for message; otherwise if predefined has been passed in as a command line argument, then the script should test for the existence of a file of that name and only continue if the file does exist
But I'm getting the following error
[: -z: binary operator expected
at the first of those if tests
Any help in explaining what's wrong with my syntax for that first if statement? Or providing an alternative syntax to achieve the same objectives.
The first if is not well-formed. This would work:
if [ -z "$message" ] && [ -z "$predefined" ]; then
or this:
if test -z "$message" && test -z "$predefined"; then
or this bash-specific, easy but dirty way:
if [[ -z "$message" ]] && [[ -z "$predefined" ]]; then
or this bash-specific proper way:
if [[ -z $message && -z $predefined ]]; then
In this last version the double-quotes are unnecessary, not a typo.
Thanks #mklement0 for the corrections in the bash-specific style, and for this final comment:
I should note that there's one case where double-quoting is still a must inside [[ ... ]], namely if you want a variable reference on the right side of a string comparison (==) to be treated as a literal:
v='[a]'
[[ $v == $v ]] # FALSE!
[[ $v == "$v" ]] # true
Without double-quoting, the right-hand side is interpreted as a pattern. Some people advocate always double-quoting variable references so as not to have to remember such subtleties. That said (from bash 3.2 on), you must NOT double-quote the right operand when regex matching with =~
test expression1 -a expression2
is true if both expressions are true.
test expression1 -o expression2
is true if either or both expressions are true.
if [ -z "$message" -a -z "$predefined" ]; then
read -p "Enter message [$defaultMessage]: " message
message=${message:-$defaultMessage}
else
if [ -n "$predefined" -a -f $base/$environment/vle/data/$predefined.txt ]; then
echo Predefined message file $predefined.txt does not exist
exit 1
fi
fi
This was able to combine 4 test into 2 while also getting rid of one nested if expression; then ; fi