I programmed a small installation program in sh.
code:
#!/bin/sh
echo $ 1
if [ "$1" ! = "install"];
then
echo "Why not install?
else
echo "Installing ..."
fi
And throws an error:
install
[: 10: missing ]
Installing ...
EDIT: Rolled back incoperation of answers into question.
if [$1 != "install"];
should be
if [ "$1" != "install" ];
Multiple problems here
The first line should start with
#!/bin/bash (or /bin/sh)
In shell script if takes a program, and [ is actually a program (it is an alias for the test program), and not a part of the syntax, so you need to make sure you space it out so that if and the '[' and anything out is separated out -- i.e.
if [ "$1" != "something" ]
Note the spaces between each and every element -- it will not work without spaces.
You also need to terminate your quoted strings, so instead of
echo "Why not install?
Make sure you have the quote at the end of line
echo "Why not install?"
Related
I'm quite new to shell scripting and have encountered an issue when trying to check for substrings within a string.
I want to build code that checks if you are running a 64bit-based system. This is indicated by the output of the uname -m && cat /etc/*release command by the x86_64 in the first line.
Here's my code:
INFO=$(uname -m && cat /etc/*release)
if [ "$INFO" == *"x86_64"* ]
then
echo "You are running a 64bit-based system!"
else
echo "Your system architecture is wrong!"
exit
fi
Although I run a 64-bit based system and the x86_64 shows up in the output of my command, the if statement still returns false, so I get the output Your system architecture is wrong!. It should be the opposite.
Can someone help me out by identifying what I did wrong? I also accept general suggestions for improving my approach, but in the first place, I'd like to know where the bug is.
Many thanks for your help!
[
The command [ is equivalent to test command. test doesn't support any kind of advanced matching. test can compare strings with = - comparing strings with == in test is a bash extension.
By doing:
[ "$INFO" == *"x86_64"* ]
You are actually running command like [ "$INFO" == <the list of files that match"x86_64"pattern> ] - the *"x86_64"* undergoes filename expansion. If you would have a file named something_x86_64_something it would be placed there, the same way cat *"x86_64"* would work.
The bash extensions [[ command supports pattern matching. Do:
if [[ "$INFO" == *"x86_64"* ]]
For portable scripting that will always work with any kind of posix shell use case:
case "$INFO" in
*x86_64*) echo yes; ;;
*) echo no; ;;
esac
With bash version >= 3 you can use a regex:
[[ "$INFO" =~ x86_64 ]]
Unsure why it's so but your code starts working after doubling the square brackets:
INFO=$(uname -m && cat /etc/*release)
if [[ "$INFO" = *x86_64* ]]
then
echo "You are running a 64bit-based system!"
else
echo "Your system architecture is wrong!"
exit
fi
Perhaps some explanation can be found under Is double square brackets [[ ]] preferable over single square brackets [ ] in Bash? and alikes.
One way to check 64 bit is to simply grep the output of /bin/arch
if /bin/arch | grep -q x86_64
then
echo "it is 64 bit"
else
echo "it is not"
fi
I have a small script that I am working on. This is only the second script that I have made using bash script.
Basically what I am wanting this script to do is take the users input and fire a command based on that choice.
As you can see the user first enters the host address of the instance they are going to ssh into and ultimately tail logs on. There are a couple things that I am not understanding.
If / Then / Else / Elif - The concept seems simple enough but perhaps how these should be used eludes me.
When I run my script through a bash parser, the parser comes back with the following message:
Line 2:
if [ "$mainmenuinput" = "1" ]; then
^-- SC2154: mainmenuinput is referenced but not assigned.
mainmenu() {
if [ "$mainmenuinput" = "1" ]; then
ssh "$customerurl" tail -f /data/jirastudio/jira/j2ee_*/log/main/current
elif [ "$mainmenuinput" = "2" ]; then
ssh "$customerurl" tail -f /data/jirastudio/confluence/j2ee_*/log/main/current
elif [ "$mainmenuinput" = "3" ]; then
ssh "$customerurl" tail -f /data/jirastudio/horde/service/log/main/current
elif [ "$mainmenuinput" = "4" ]; then
ssh "$customerurl" tail -f /data/jirastudio/apache/logs/access_log
fi
}
printf "\nEnter the customers host URL:\n"
read -r customerurl
printf "Press 1 for JIRA\n"
printf "Press 2 for Confluence\n"
printf "Press 3 for Horde\n"
printf "Press 4 for Apache Access\n"
printf "Press 5 for Apache Error\n"
read -p -r "Make your choice:" "$mainmenuinput"
Looking up the SC2154 entry I found that it means this:
ShellCheck has noticed that you reference a variable that is not assigned. Double check that the variable is indeed assigned, and that the name is not misspelled.
I am a little confused on what that means. If someone can explain that, I would greatly appreciate it.
As it stands, when I run the script, it pauses to wait for the user to enter the host address. The user hits ENTER and the script then presents them with the menu to have them choose which log they want to tail. The menu looks a little odd:
Press 1 for JIRA
Press 2 for Confluence
Press 3 for Horde
Press 4 for Apache Access
Press 5 for Apache Error
-r
Im not sure why the -r is showing up at the end of the menu. When a selection is made, the script ends and outputs this:
./tail_logs.sh: line 23: read:Make your choice:': not a valid identifier`
Any help with this would be appreciated or if anything a push in the right direction. I love figuring this stuff out but sometimes, its helpful to get shoved at least in the general direction of the error/resolution.
Thanks
EDIT 1
Ok, I updated my script with your suggestions. It seemed to still balk at a few things. For example:
(mainmenu "$customerurl" "$mainmenuinput")
Using ShellCheck I got back this:
Line 1:
(mainmenu "$customerurl" "$mainmenuinput") {
^-- SC2154: customerurl is referenced but not assigned.
^-- SC2154: mainmenuinput is referenced but not assigned.
^-- SC1070: Parsing stopped here. Mismatched keywords or invalid parentheses?
If I write this out like:
mainmenu() { then it does not complain. Also, if I run the script with it typed out as per the suggested way, I get an error about `syntax error near unexpected token '{'
The current code looks like this:
#!/bin/sh
mainmenu() {
echo "$1"
echo "$2"
if [ "$2" = "1" ]; then
ssh "$1" tail -f "/data/jirastudio/jira/j2ee_*/log/main/current"
elif [ "$2" = "2" ]; then
ssh "$1" tail -f "/data/jirastudio/confluence/j2ee_*/log/main/current"
elif [ "$2" = "3" ]; then
ssh "$1" tail -f "/data/jirastudio/horde/service/log/main/current"
elif [ "$2" = "4" ]; then
ssh "$1" tail -f "/data/jirastudio/apache/logs/access_log"
elif [ "$2" > 4 || < 1 ]; then
echo "Uh uh uh, you didnt say the magic word! The number you picked isnt in the list. Pick again."
fi
}
echo
echo "Enter the customers host address:"
read -r customerurl
echo "Press 1 for JIRA"
echo "Press 2 for Confluence"
echo "Press 3 for Horde"
echo "Press 4 for Apache Access"
echo "Press 5 for Apache Error"
read -r -p "Pick a number: " mainmenuinput
I get no errors when running this. But when I make a selection, the script ends and does not output the tail command at all. Also, Im not sure if I am validating user input outside of 1-4 correctly with the last elif statement although if I change this to else I get an error when I run the script.
I think my issue is in the first part of the function?
mainmenu() {
echo "$1"
echo "$2"
Without having $hostAddress and mainMenuInput does the script not know what should be assigned to $1 and $2 or does it automatically assign the first thing typed in to these variables?
The main problems are with the read command at the end. First, whatever immediately follows the -p option is used as a prompt string; in this case, the next argument is "-r", so it prints that as a prompt. You clearly want "Make your choice:" to be the prompt, so that must go immediately after -p (i.e. use either read -r -p "Make your choice:" ... or read -p "Make your choice:" -r ...). Second, when you use $mainmenuinput, it replaces that with the current value of mainmenuinput. In the shell, you use $variable to get the value of a variable, not to set it. With both of these problems corrected, the last command becomes:
read -p "Make your choice:" -r mainmenuinput
There's also another important thing: after reading the users' input, you need to actually call the mainmenu function. So just add mainmenu as the last line.
As for the if ... then ... elif ... structure, yours looks fine; I'm not sure what the question is. Although personally I'd add an else clause that printed an error that the option was not valid.
I do have some stylistic/best practice recommendations, though:
It's best to pass information to functions in the form of arguments, rather than global variables. That is, rather than using customerurl and mainmenuinput directly in the function, pass them as arguments (mainmenu "$customerurl" "$mainmenuinput"), then reference those arguments ("$1" and "$2") inside the functions. This doesn't matter much in a small script like this, but having clear distinctions between the variables used by different parts of a program makes things much easier to keep straight in larger programs.
In shell scripts, printf is the best way to do complex things like printing lines without a linefeed at the end, or translating escape characters... but if you're just doing a standard print-a-line-with-a-linefeed-at-the-end, echo is simpler. Thus, I'd replace the various printf "something\n" commands with echo "something", and printf "\nEnter the customers host URL:\n" with:
echo
echo "Enter the customers host URL:"
In the command
ssh "$customerurl" tail -f /data/jirastudio/jira/j2ee_*/log/main/current
(or ssh "$1" ... if you follow my recommendation about arguments instead of global variables), the wildcard (*) will be expanded on the local computer before being handed to ssh and passed to the remote computer to be executed. It'd be best to quote that argument to prevent that:
ssh "$customerurl" tail -f "/data/jirastudio/jira/j2ee_*/log/main/current"
Note that the quotes will be removed before it's passed to ssh and then to the remote computer, so they will not prevent the wildcard from being expanded on the remote computer.
The thing you're calling a URL isn't actually a URL; URLs are things like "https://stackoverflow.com/questions". They start with a protocol (or "scheme") like "http" or "ftp", then "://", then a server name, then "/", etc. ssh just takes a raw server name (optionally with a username, in the form user#server).
Update, based on EDIT 1: I wasn't clear on how to call the function; your definition (using mainmenu() { ...) is correct, but having defined the function you then need to actually run the function. Do to this, change the end of the script to something like this:
...
echo "Press 5 for Apache Error"
read -r -p "Pick a number: " mainmenuinput
mainmenu "$customerurl" "$mainmenuinput"
This will run the function, with the first argument ($1) set to "$customerurl", and second argument ($2) set to "$mainmenuinput".
There's also a problem with the elif clause you added in the function. The shell's syntax for test expressions is really really weird (mostly for historical reasons). Also, there are three common variants, the original [ ... ] (which is actually a command) which has the weirdest syntax, bash's [[ ... ]] variant (much cleaner syntax, but not available available in generic POSIX shells), and (( ... )) (cleaner syntax, math- rather than string-oriented, not portable). See BashFAQ #31 for details.
For what you're trying to do, any of these would work:
elif [ "$2" -gt 4 -o "$2" -lt 1 ]; then
# [ ... ] doesn't use || or &&, and uses -lt etc for numeric comparisons.
# < and > do string comparisons, which are ... different. And you'd
# need to quote them to keep them from being mistaken for redirects.
# Also, you need to specify the "$2" explicitly for each comparison.
elif [[ "$2" -gt 4 || "$2" -lt 1 ]]; then
# [[ ... ]] uses || and &&, but still uses -lt etc for numeric comparisons.
# < and > still do string comparisons, but don't need to be quoted
elif (( $2 > 4 || $2 < 1 )); then
# All numeric here, so < and > work
But there's still a problem, since the user might have entered something that isn't a number at all (just pressed return, typed "wibble", etc.), and in all of these cases numeric comparison will fail. Solution: skip the test, and use else instead of elif:
...
elif [ "$2" = "4" ]; then
ssh "$1" tail -f "/data/jirastudio/apache/logs/access_log"
else
echo "Uh uh uh, you didnt say the magic word! The number you picked isnt in the list. Pick again."
fi
}
... that way, if any of the previous conditions aren't met for any reason at all, it'll print the error message.
I have the following bash script file callee.sh which is being called from another script file caller.sh.
The callee.sh is as follows:
if [ $1 -eq 1 ];
then
echo inside $1
source ~/MYPROGRAMSRC/standAloneWordCount.sh $2
#echo "inside standalone branch"
#echo $1
elif [ $1 -eq 2 ];
then
#echo "inside distributed branch"
#echo $1
else
echo invalid option for first argument-\n Options:\n "distributed"\n or\n "standalone"\n
fi
As most people might be able to tell, this is a script I use to decide whether to run hadoop in distributed or standAlone mode depending on the arguments.
This script is called from caller.sh as follows
source callee.sh $2 $counterGlobal
where $2 is a number either 1 or 2 and $counterGlobal is some integer.
My problem is that the if condition in callee.sh never evaluates to True and hence my script standAloneWordCount.sh which I call from within callee.sh is never called. I am running with bash shell and have tried many variants of the if statement like:
if [ $(($1 == 1 )) ] -- (1)
In an echo statement just above the line -- (1) , the expression $(($1 == 1)) evaluates to 1 so I am baffled as to why I am unable to satisfy the if condition.
Also I keep getting the error where it says:
syntax error near unexpected token `else'
if anyone could help me out with these two errors, it would be much appreciated. As I've run out of ideas.
Thanks in advance!
have tried many variants of the if statement like:
if [ $(($1 == 1 )) ]
You should instead be saying:
if (($1 == 1)); then
...
fi
Regarding the Syntax error near unexpected tokenelse'`, it's not because of any code that you've shown above. It seems to originate from some other portion of your script.
If you're using bash, try using double square brackets:
if [[ $1 -eq 1 ]]; then
echo "inside 1"
fi
As for the syntax error, you need quotes around your text (which also means escaping the existing quotes or use single quotes):
echo -e "invalid option for first argument-\n Options:\n \"distributed\"\n or\n \"standalone\"\n"
The -e flag is there to let bash know you want the \n to evaluate to a newline.
Can anyone tell me why this is always saying that the directory is not writable, when it absolutely is?
$dnam="/home/bryan/renametest/C D"
# Is the directory writable
err=0
if [ ! -w $dnam ]
then
# Not writable. Pop the error and exit.
echo "Directory $dnam is not writable"
err=1
fi
You need double-quotes around $dnam -- without them, it's interpreted as two separate shell words, "/home/bryan/renametest/C" and "D", which makes an invalid test expression and hence fails. This should work:
if [ ! -w "$dnam" ]
#tink's suggestion of [[ ]] is a cleaner way of doing tests like this, but is only available in bash (and some other shells with extended syntax). The fact that you get [[: not found means you're using a fairly basic shell, not bash.
I see multiple problems:
You are using a space inside your variable. This is not illegal, but in combination line you use the variable unescaped and generate the following command:
if [ ! -w /home/bryan/renametest/C D ]
This is not a valid syntax. The simplest way to fix this is changing the line to
if [ ! -w "$dnam" ]
The next problem is worse: On my system, help test returns the text:
-w FILE True if the file is writable by you.
Which means, the command doesn't support directories but only files. If you want to check if a directory is writable, you will have to use a different command
As everyone else said, the $dnam variable needs double quotes. Here's why:
The [ ... ] is an alias to the test command. If you look in your system, you will see a file called /bin/[ or maybe /bin/usr/[. On some systems, this is a hard link to /bin/test or /bin/usr/test. The if statement executes what comes after the if, and if that command returns a zero exit status, the if statement will execute the then clause. Otherwise, if there is an else clause, that will execute instead.
To allow for boolean testing, Unix included the test command, so you could do this:
if test -d "$directory"
then
echo "Directory $directory exists!"
fi
Later on, the /bin/[ was added as syntactic sugar. This is identical to the above:
if [ -d "$directory" ]
then
echo "Directory $directory exists!"
fi
Now, both [ and test are builtin commands, but they are *still commands. This means that the shell interpolates the command and then executes it.
Try executing the following:
$ set -xv # Turns on shell debugging
$ dnam="/home/bryan/renametest/C D"
dnam="/home/bryan/renametest/C D"
+ dnam='/home/bryan/renametest/C D'
$ test -d $dnam
test -d $dnam
+ test -d /home/bryan/renametest/C D
$ echo $?
echo $?
+ echo 1
1
$ test -d "$dnam" # Now with quotes
test -d $dnam
+ test -d "/home/bryan/renametest/C D"
$ echo $?
echo $?
+ echo 0
0
$ set +xv # Turn off the debuggin
Each command is echoed twice. The first time as written, and the second time after the line is interpolated. As part of the interpolation, the shell splits parameters on white space. As you can see, the test command is testing the presence of /home/bryan/renamtest/C which doesn't exist and thus not writable. I'm actually surprised that the test command didn't print an error message because you passed it an extra parameter.
In the second attempt, you added quotes. These quotes prevented the shell from splitting your parameters on the space and keep the directory name as a single parameter.
Since [ ... ] is a command, you have to take into account the shell's interpolation of variables and other issues. And, if you're not absolutely careful, you can end up with errors.
Even worse, sometimes the [ ... ] might work and sometimes it might not. If your directory name didn't contain spaces, it will work as expected. Imagine you're writing a program, and you test it and everything works because all directories you've tried don't have spaces. Then, someone uses your program, but has a space in the directory. A substantial number of shell script bugs are do to this type of issue in if statements.
This is why Bash introduced the [[ ... ]] tests. The [[ isn't a command but a statement. This means that the shell doesn't directly interpolate the results. Instead, the parameters are parsed, and then any interpolation is done. Thus, this would have worked:
dnam="/home/bryan/renametest/C D" # No "$" in front of the variable!
# Is the directory writable
if [[ ! -w $dnam ]] # No quotation marks needed!
then
# Not writable. Pop the error and exit.
echo "Directory $dnam is not writable"
err=1
fi
It's almost always better to use the [[ ... ]] test rather than the [ ... ] test, so go ahead and get into the habit.
One more minor error, you had:
$dnam="/home/bryan/renametest/C D"
This gets interpolated by the shell, so the variable being set is whatever the value of $dnam just happens to be. If $dnam happened to equal "foo", you would been doing this:
foo="/home/bryan/renametest/C D"
Not what you want.
You want to leave the $ off when you set variables:
dnam="/home/bryan/renametest/C D"
I am attempting to find a binary file in a Linux system using something like this:
if [ -f `which $1` ] then
echo "File Found"
else
echo "File not Found"
fi
while the code works fine the problem is "which" will return a null operator which BASH interprets as something existing so a file always comes back found. Any suggestions would be great.
Thanks
Update
After a bit more thought, there is no reason to use [[ ]] (or [ ] for that matter). There is even no reason to use command substitution either $()
if which "$1" > /dev/null 2>&1; then
echo "found"
else
echo "not found"
fi
If you're using bash then please use the [[ ]] construct. One of the benefits (among many) is that it doesn't have this problem
[[ -f $(which $1) ]] && echo found
Also, `` is deprecated, use $() instead
if [ `which "$1"` != "" ]; then
which won't return "" when it finds the binary.
I like 'hash' for this (if you're a bash user..) (and it's actually more portable behavior than which)
hash blahblah
bash: hash: lklkj: not found
hash /bin/ls <-- silently successful
This method works on Linux and OSX similarly, where-as 'which' has different behavior.