Bash Script syntax error: unexpected end of file
hello everyone,
this question has been asked on this forum a 100 times. I went through all of the posts but here is a simple piece of code and am unable to figure my error. Can someone pls help? #!/bin/sh --debug build_dir=`dirname $0` export BUILD_ID=SCAQBAF export BUILD_VER=0111 if [ "$BUILD_ID" = "SCAQBAF" ] then echo hai fi echo bye exit 0 i dont see any error if i remove everything after the "if" stmt. What is wrong with the if syntax here? |
Hi,
that works for me if I remove the "--debug". This prompts the question what is /bin/sh linked to on your system? Eg Code:
readlink -f /bin/sh |
thanks evo2 for replying!
Its bash shell ls -ltr /bin/sh lrwxrwxrwx 1 root root 4 Feb 25 2010 /bin/sh -> bash |
Hi,
ok, that script should work with bash. So, next guess is that the script you are running is somehow subtly different to what you pasted into your post. Could you perhaps attach the actual file and post it here? (The "Manage Attachments" button in the full or "advanced" posting interface, or if you do "Preview Post") Evo2. |
1 Attachment(s)
Have attached the file as txt
|
Well, I don't get any errors for sh or bash, with or without --debug.
Possibly a version thing.?? My /bin/sh links to /bin/bash which is Code:
bash --version PS you can check the actual content thus Code:
od -c t.sh |
Bash version I have is
GNU bash, version 3.2.48(1)-release (x86_64-pc-linux-gnu) PS adding [[ gives me syntax error on this version. |
The file you attached uses DOS line endings. Emacs reported that when I opened it.
In brief, a file written and saved in DOS/Windows uses a special character sequence to indicate the end of a line. Linux uses Unix line endings: a subset of the DOS/Windows character sequence. The consequence of this is, when Linux tries to read a DOS/Windows file, Linux "sees" more characters than you would expect. The extra character is not printable--you cannot see it when you examine the file in a text editor. It is this extra character per line that causes your problem. I was able to reproduce your "unexpected end of file" error by running Code:
user@localhost$ bash dummy.txt You need to convert the line endings in the file to Unix-style line endings with the dos2unix command or with this simple sed command: Code:
sed -i 's@\r@@' dummy.txt I'd suggest you get acquainted with native Linux text editors and work with them for Linux scripts/configuration files. |
Definitely try the od cmd; even in bash 3 I'm pretty sure [[ ]] should work.
... and DarkHelmet said what I was thinking: DOS line-endings; a common mistake. :) |
Hi,
indeed was was dos line endinings: Code:
% readlink -f /bin/sh Evo2. |
Since the main problem has been diagnosed, I'd like to post a few comments about the script itself in the OP.
1) First of all, please use [code][/code] tags around your code and data, to preserve formatting and to improve readability. Please do not use quote tags, colors, or other fancy formatting. 2) Clean, consistent formatting makes code readable and more easily debuggable. Indent all your sub-commands, and separate logical sections with whitespace. Add comments anywhere the code isn't completely obvious (and remember, what seems obvious to you now will not be a year or so down the line). Many people also think that it makes it more readable to place the "do/then" keywords on the same line as the "for/while/until/if" keywords. It more clearly separates the outside block from the inside block. Code:
for var in <list> ; do 3) #!/bin/sh is used for interpreting scripts in posix-compliant lowest-common-denominator mode. This is mostly recommended for system startup scripts and other cases where portability and standardization are more important than convenience. When this isn't required, you should probably use #!/bin/bash or another shell that has more modern, advanced features available, such as ksh or zsh. 4) $(..) is highly recommended over `..` 5) Environment variables are generally all upper-case. So while not absolutely necessary, it's good practice to keep your own user variables in lower-case or mixed-case, to help differentiate them. |
thank you all for helping me get resolved with this trivial error! Much appreciated :) will keep in mind these comments.
|
All times are GMT -5. The time now is 10:57 PM. |