"test: too many arguments" message because of special character * while using test command on bash to compare two strings [duplicate] - string

This question already has answers here:
Meaning of "[: too many arguments" error from if [] (square brackets)
(6 answers)
Closed 5 years ago.
I'm new to shell scripting and I'm having some trouble while using the "test" command and the special character * to compare two strings.
I have to write a shell script which, for every element(both files and directories) contained in the directory passed as the first argument, has to write something(for the solving of my problem it is not relevant to know what has to be written down) on the file "summary.out". What's more, there's a string passed as the second argument. Those files/directories beginning with this string must be ignored(nothing has to be written on summary.out).
Here is the code:
#!/bin/bash
TEMP=NULL
cd "$1"
for i in *
do
if test "$i" != "$2"*;then #Here is where the error comes from
if test -f "$i";then
TEMP="$i - `head -c 10 "$i"`"
elif test -d "$i";then
TEMP="$i - `ls -1 "$i" | wc -l`"
fi
echo $TEMP >> summary.out
fi
done
The error comes from the test which checks whether the current file/directory begins with the string passed as second argument, and it takes place every iteration of the for cycle. It states:"test: too many arguments"
Now, I have performed some tests which showed that the problem has nothing to do with blank spaces inside the $i or $1. The problem is linked to the fact that I use the special character * in the test(if I remove it, everything works fine).
Why can't "test" handle * ? What can I do to fix that?

* gets expanded by the shell.
In bash, you can use [[ ... ]] for conditions instead of test. They support patterns on the right hand side - * is not expanded, as double square brackets are a keyword with higher precedence.
if [[ a == * ]] ; then
echo Matches
else
echo Doesn\'t match
fi

Related

Am I using the correct syntax for my shell script? [duplicate]

This question already has answers here:
Why should there be spaces around '[' and ']' in Bash?
(5 answers)
Command not found error in Bash variable assignment
(5 answers)
Closed 4 years ago.
I wrote a shell script that gets a value from a file and based on that value I want to echo a particular message. My console keeps on saying that there is an error on line 7 and 9. Any suggestions on how to fix it will be greatly appreciated.
export JAVA_HOME='/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home'
echo $JAVA_HOME
export CLASSPATH='/Users/edgarjohnson/Desktop/JarFiles/mlDownload.jar:/ddc/config'
echo $CLASSPATH
var=$(cat /ddc/config/LastRefreshDate.dat)
echo $var
if [$var > 0 ];then
echo "Run Get Latest Update Class"
elif [$var = 0]; then
echo "No need to run any updates"
fi
After [ and before ] there must be a space. Otherwise the variable is substituted and the shell will try to execute a program called [Whatever.
[ itself is actually just a binary which is executed with var's content, =, 0 and ] as arguments and its return code is used to determine whether the if or else branch should be taken.
However the operators used are not really the ones you intend to use, e.g. > is interpreted as shell redirect creating a file called 0 (or overwritting it) and is not actually comparing anything, use -gt instead. = checks string equality, -eq checks value equality.
As mentioned in the comments it may be better to use [[ ]] instead of [ ].

What would cause the BASH error "[: too many arguments" after taking measures for special characters in strings?

I'm writing a simple script to check some repositories updates and, if needed, I'm making new packages from these updates to install new versions of those programs it refers to (in Arch Linux). So I made some testing before executing the real script.
The problem is that I'm getting the error [: excessive number of arguments (but I think the proper translation would be [: too many arguments) from this piece of code:
# Won't work despite the double quoted $r
if [ "$r" == *"irt"* ]; then
echo "TEST"
fi
The code is fixed by adding double square brackets which I did thanks to this SO answer made by #user568458:
# Makes the code works
if [[ "$r" == *"irt"* ]]; then
echo "TEST"
fi
Note that $r is defined by:
# Double quotes should fix it, right? Those special characters/multi-lines
r="$(ls)"
Also note that everything is inside a loop and the loop progress with success. The problems occurs every time the if comparison matches, not printing the "TEST" issued, jumping straight to the next iteration of the loop (no problem: no code exists after this if).
My question is: why would the error happens every time the string matches? By my understanding, the double quotes would suffice to fix it. Also, If I count on double square brackets to fix it, some shells won't recognize it (refers to the answer mentioned above). What's the alternative?
Shell scripting seems a whole new programming paradigm.. I never quite grasp the details and fail to secure a great source for that.
The single bracket is a shell builtin, as opposed to the double bracket which is a shell keyword. The difference is that a builtin behaves like a command: word splitting, file pattern matching, etc. occur when the shell parses the command. If you have files that match the pattern *irt*, say file1irt.txt and file2irt.txt, then when the shell parses the command
[ "$r" = *irt* ]
it expands $r, matches all files matching the pattern *irt*, and eventually sees the command:
[ expansion_of_r = file1irt.txt file2irt.txt ]
which yields an error. No quotes can fix that. In fact, the single bracket form can't handle pattern matching at all.
On the other hand, the double brackets are not handled like commands; Bash will not perform any word splitting nor file pattern matching, so it really sees
[[ "expansion_of_r" = *irt* ]]
In this case, the right hand side is a pattern, so Bash tests whether the left hand side matches that pattern.
For a portable alternative, you can use:
case "$r" in
(*irt*) echo "TEST" ;;
esac
But now you have a horrible anti-pattern here. You're doing:
r=$(ls)
if [[ "$r" = *irt* ]]; then
echo "TEST"
fi
What I understand is that you want to know whether there are files matching the pattern *irt* in the current directory. A portable possibility is:
for f in *irt*; do
if [ -e "$f" ]; then
echo "TEST"
break
fi
done
Since you're checking for files with a certain file name, I'd suggest to use find explicitly. Something like
r="$(find . -name '*irt*' 2> /dev/null)"
if [ ! -z "$r" ]; then
echo "found: $r"
fi

"if[ 0 -lt 1] command not found" error in shell script [duplicate]

This question already has answers here:
Why should there be spaces around '[' and ']' in Bash?
(5 answers)
Why is whitespace sometimes needed around metacharacters?
(5 answers)
Closed 5 years ago.
I got error message as if[ 0 -lt 1] command not found. I just started shell scripting. I don't know what's wrong in my code:
if[ $# -lt 1 ]
then
echo "Give a number as a parameter. Try again."
else
n=$1
sum= 0
sd=0
while[ $n -gt 0 ]
do
sd=`expr $n % 10`
sum=`expr $sum + $sd`
n=`expr $n / 10`
done
echo "Sum of digits for $1 is $sum"
You need a space between if and [. You'll have the same issue after while.
The [ ] notation is kind of an oddity in shell. It looks like part of the language, but it actually isn't. The if and while words always need to be followed by whitespace and then a command, which is executed, and considered to be true or false according to whether its exit code is zero or nonzero.
So there is actually a command named [ which evaluates the conditions given on its command line, and terminates with an exit code according to whether the condition evaluated true or false. You can see an executable in the /usr/bin directory on most systems (though the shell usually has a built-in version for efficiency). It works the same as test.
Also, keep in mind that if needs a matching fi after the else clause.
Check out https://www.shellcheck.net/ (Open Source - free)
It allows you to check your shell scripts before running them. You just copy your shell script into the browser and do a syntax check, you can also run locally.
Why?
Well, this I think will really help you learn what you are doing wrong.
i.e. Fix spacing errors etc.
Example Output:
$ shellcheck myscript
Line 1:
if[ $# -lt 1 ]
^-- SC1046: Couldn't find 'fi' for this 'if'.
^-- SC1073: Couldn't parse this if expression.
^-- SC1069: You need a space before the [.
Line 8:
while[ $n -gt 0 ]
^-- SC1069: You need a space before the [.
Line 15:
^-- SC1047: Expected 'fi' matching previously mentioned 'if'.
^-- SC1072: Expected 'fi'. Fix any mentioned problems and try again.
$

Shell Script working with multiple files [duplicate]

This question already has answers here:
How to iterate over arguments in a Bash script
(9 answers)
Closed 5 years ago.
I have this code below:
#!/bin/bash
filename=$1
file_extension=$( echo $1 | cut -d. -f2 )
directory=${filename%.*}
if [[ -z $filename ]]; then
echo "You forgot to include the file name, like this:"
echo "./convert-pdf.sh my_document.pdf"
else
if [[ $file_extension = 'pdf' ]]; then
[[ ! -d $directory ]] && mkdir $directory
convert $filename -density 300 $directory/page_%04d.jpg
else
echo "ERROR! You must use ONLY PDF files!"
fi
fi
And it is working perfectly well!
I would like to create a script which I can do something like this: ./script.sh *.pdf
How can I do it? Using asterisk.
Thank you for your time!
Firstly realize that the shell will expand *.pdf to a list of arguments. This means that your shell script will never ever see the *. Instead it will get a list of arguments.
You can use a construction like the following:
#!/bin/bash
function convert() {
local filename=$1
# do your thing here
}
if (( $# < 1 )); then
# give your error message about missing arguments
fi
while (( $# > 0 )); do
convert "$1"
shift
done
What this does is first wrap your functionality in a function called convert. Then for the main code it first checks the number of arguments passed to the script, if this is less than 1 (i.e. none) you give the error that a filename should be passed. Then you go into a while loop which is executed as long as there are arguments remaining. The first argument you pass to the convert function which does what your script already does. Then the shift operation is performed, what this does is it throws away the first argument and then shifts all the remaining arguments "left" by one place, that is what was $2 now is $1, what was $3 now is $2, etc. By doing this in the while loop until the argument list is empty you go through all the arguments.
By the way, your initial assignments have a few issues:
you can't assume that the filename has an extension, your code could match a dot in some directory path instead.
your directory assignment seems to be splitting on . instead of /
your directory assignment will contain the filename if no absolute or relative path was given, i.e. only a bare filename
...
I think you should spend a bit more time on robustness
Wrap your code in a loop. That is, instead of:
filename=$1
: code goes here
use:
for filename in "$#"; do
: put your code here
done

Linux Shell Scritping - checking arguments [duplicate]

This question already has answers here:
Why should there be spaces around '[' and ']' in Bash?
(5 answers)
Closed 6 years ago.
Trying to make a program where it takes two arguments from the command line and adds them together. However if there are not two arguments passed it needs to ask for two arguments.
if [$# = 2]; then
ans=$(($1 + $2))
echo "$1 + $2 = $ans"
else
echo "Pass me two Arguments!"
fi
What is the correct way to check whether the number of arguments is equivalent to a number?
You got it but just forgot some escaping quotes and the spaces before/after the test ([$# = 2]). Fixed:
if [ "$#" = 2 ]; then
ans=$(($1 + $2))
echo "$1 + $2 = $ans"
else
echo "Pass me two Arguments!"
fi
Odd as it may seem, [ is actually the name of an executable just like echo, ls and what have you:
$ which [
/usr/bin/[
This means that if you don't have a space after [, you're trying to start a program called [your_statement. The space is needed to separate the executable from its arguments.
Most *nix systems allow you to use the equivalent test executable rather than [ for a more intuitive syntax: if test "$#" = 2; then ...
By omitting the quotes in the if statement, bash/shell interprets everything following the # as a comment and so does SO's code formatting tool (everything after if [$ is greyed out in your code but not in mine because I added the double quotes in "$#").
Btw. ShellCheck can be very helpful.

Resources