Linux Script Unexpected end of file error - linux

I am new to shell scripting. I was trying to write a script to which is throwing an unexpected end of file error. I have check other solutions on stackoverflow, however I coul not solve the here. Any help would be appreciated. My script is
if [ "$(/etc/init.d/tomcat7 status)" == " * Tomcat servlet engine is not running." ]; then /etc/init.d/tomcat7 start; fi
As suggested I tried creating this in linux and now I get an error [: * Tomcat servlet engine is not running.: unexpected operator

Since you created the file on Windows your original problem was most likely due to a mismatch of line-break characters. Windows encodes line-breaks as CR-LF, while Linux/Unix uses just LF and Mac OS just CR. You can fix that with e.g.
recode ibmpc..latin1 your.sh
Also you should specify the interpreter in the first line of the script:
#!/bin/bash
Your script should probably look somewhat like this:
#!/bin/bash
if [ "$(/etc/init.d/tomcat7 status)" == " * Tomcat servlet engine is not running." ]; then
/etc/init.d/tomcat7 start
fi

As you wrote the script on windows most probably the problem is the different encoding of line-end characters \r\n on windows while a single \n on linux.
Try using dos2unix on your script and run it again.

Solved this looking at [ :Unexpected operator in shell programming.
I had to run it as bash instead of sh.

Related

printf in nodejs execSync gives error - the system cannot find the file specified

In node when using ..
var child_process = require('child_process')
child_process.execSync("printf 'a'") // works fine
child_process.execSync("printf '<a>'") // throws the system cannot find the file specified
I get the error .. the system cannot find the file specified.
Anyone got any ideas how to fix this? I need to use printf. All I want to do is print <a>
I am using Windows GIT bash. Node v6.11.3
On the command line .. printf '<a>' works fine but printf \'<a>\' gives the same error.
Try swapping quote characters:
child_process.execSync('printf "<a>"')
With the quotes the other way around, the executing shell (which is cmd.exe in Windows, I believe) seems to think that you want to redirect a file called "a" into printf (like printf < a).

Read filename with * shell bash

I'am new in Linux and I want to write a bash script that can read in a file name of a directory that starts with LED + some numbers.(Ex.: LED5.5.002)
In that directory there is only one file that will starts with LED. The problem is that this file will every time be updated, so the next time it will be for example LED6.5.012 and counting.
I searched and tried a little bit and came to this solution:
export fspec=/home/led/LED*
LedV=`basename $fspec`
echo $LedV
If I give in those commands one by one in my terminal it works fine, LedV= LED5.5.002 but if i run it in a bash scripts it gives the result: LedV = LED*
I search after another solution:
a=/home/led/LED*
LedV=$(basename $a)
echo $LedV
but here again the same, if i give it in one by one it's ok but in a script: LedV = LED*.
It's probably something small but because of my lack of knowledge over Linux I cannot find it. So can someone tell what is wrong?
Thanks! Jan
Shell expansions don't happen on scalar assignments, so in
varname=foo*
the expansion of "$varname" will literally be "foo*". It's more confusing when you consider that echo $varname (or in your case basename $varname; either way without the double quotes) will cause the expansion itself to be treated as a glob, so you may well think the variable contains all those filenames.
Array expansions are another story. You might just want
fspec=( /path/LED* )
echo "${fspec[0]##*/}" # A parameter expansion to strip off the dirname
That will work fine for bash. Since POSIX sh doesn't have arrays like this, I like to give an alternative approach:
for fspec in /path/LED*; do
break
done
echo "${fspec##*/}"
pwd
/usr/local/src
ls -1 /usr/local/src/mysql*
/usr/local/src/mysql-cluster-gpl-7.3.4-linux-glibc2.5-x86_64.tar.gz
/usr/local/src/mysql-dump_test_all_dbs.sql
if you only have 1 file, you will only get 1 result
MyFile=`ls -1 /home/led/LED*`

syntax error near unexpected token ' - bash

I have a written a sample script on my Mac
#!/bin/bash
test() {
echo "Example"
}
test
exit 0
and this works fine by displaying Example
When I run this script on a RedHat machine, it says
syntax error near unexpected token '
I checked that bash is available using
cat /etc/shells
which bash shows /bin/bash
Did anyone come across the same issue ?
Thanks in advance !
It could be a file encoding issue.
I have encountered file type encoding issues when working on files between different operating systems and editors - in my case particularly between Linux and Windows systems.
I suggest checking your file's encoding to make sure it is suitable for the target linux environment. I guess an encoding issue is less likely given you are using a MAC than if you had used a Windows text editor, however I think file encoding is still worth considering.
--- EDIT (Add an actual solution as recommended by #Potatoswatter)
To demonstrate how file type encoding could be this issue, I copy/pasted your example script into Notepad in Windows (I don't have access to a Mac), then copied it to a linux machine and ran it:
jdt#cookielin01:~/windows> sh ./originalfile
./originalfile: line 2: syntax error near unexpected token `$'{\r''
'/originalfile: line 2: `test() {
In this case, Notepad saved the file with carriage returns and linefeeds, causing the error shown above. The \r indicates a carriage return (Linux systems terminate lines with linefeeds \n only).
On the linux machine, you could test this theory by running the following to strip carriage returns from the file, if they are present:
cat originalfile | tr -d "\r" > newfile
Then try to run the new file sh ./newfile . If this works, the issue was carriage returns as hidden characters.
Note: This is not an exact replication of your environment (I don't have access to a Mac), however it seems likely to me that the issue is that an editor, somewhere, saved carriage returns into the file.
--- /EDIT
To elaborate a little, operating systems and editors can have different file encoding defaults. Typically, applications and editors will influence the filetype encoding used, for instance, I think Microsoft Notepad and Notepad++ default to Windows-1252. There may be newline differences to consider too (In Windows environments, a carriage return and linefeed is often used to terminate lines in files, whilst in Linux and OSX, only a Linefeed is usually used).
A similar question and answer that references file encoding is here: bad character showing up in bash script execution
try something like
$ sudo apt-get install dos2unix
$ dos2unix offendingfile
Easy way to convert example.sh file to UNIX if you are working in Windows is to use NotePad++ (Edit>EOL Conversion>UNIX/OSX Format)
You can also set the default EOL in notepad++ (Settings>Preferences>New Document/Default Directory>select Unix/OSX under the Format box)
Thanks #jdt for your answer.
Following that, and since I keep having this issue with carriage return, I wrote that small script. Only run carriage_return and you'll be prompted for the file to "clean".
https://gist.github.com/kartonnade/44e9842ed15cf21a3700
alias carriage_return=remove_carriage_return
remove_carriage_return(){
# cygwin throws error like :
# syntax error near unexpected token `$'{\r''
# due to carriage return
# this function runs the following
# cat originalfile | tr -d "\r" > newfile
read -p "File to clean ? "
file_to_clean=$REPLY
temp_file_to_clean=$file_to_clean'_'
# file to clean => temporary clean file
remove_carriage_return_one='cat '$file_to_clean' | tr -d "\r" > '
remove_carriage_return_one=$remove_carriage_return_one$temp_file_to_clean
# temporary clean file => new clean file
remove_carriage_return_two='cat '$temp_file_to_clean' | tr -d "\r" > '
remove_carriage_return_two=$remove_carriage_return_two$file_to_clean
eval $remove_carriage_return_one
eval $remove_carriage_return_two
# remove temporary clean file
eval 'rm '$temp_file_to_clean
}
I want to add to the answer above is how to check if it is carriage return issue in Unix like environment (I tested in MacOS)
1) Using cat
cat -e my_file_name
If you see the lines ended with ^M$, then yes, it is the carriage return issue.
2) Find first line with carriage return character
grep -r $'\r' Grader.sh | head -1
3) Using vim
vim my_file_name
Then in vim, type
:set ff
If you see fileformat=dos, then the file is from a dos environment which contains a carriage return.
After finding out, you can use the above mentioned methods by other people to correct your file.
I had the same problem when i was working with armbian linux and Windows .
i was trying to coppy my codes from windows to armbian and when i run it this Error Pops Up. My problem Solved this way :
1- try to Coppy your files from windows using WinSCP .
2- make sure that your file name does not have () characters

Translating Cygwin path to Windows

HI,
I have cygwin installed in my Windows system.
I have written two function in my profile file so that every time I open vi/vim, it will open with gvim.
But with this one of the issue, the windows path and Cygwin path. I tried with Cygpath as below:
function vi ()
{
win_file_path=$(cygpath -w $*)
gvim "$win_file_path" &
}
Bu with this, when ever I open a file like this: "vi /etc/exports +5", it will result in error. So let me know if any of you have any solution.
You can treat the file arguments only:
function vi ()
{
local -a viargs
local a
while [[ $# -gt 0 ]]
do
a="$1"
if [ -e "$a" ]; then a="$(cygpath -w "$a")"; fi
viargs[${#viargs[#]}]="$a"
shift
done
gvim "${viargs[#]}" &
}
Instead of being 'smart' about existing files like this, feel free to simplify to treat just the first argument :)
In recent bash versions you can replace the ugly line
viargs[${#viargs[#]}]="$a"
with
viargs+=( "$a" )
cyg-wrapper has been written for this sole purpose.
NB: See also the related wikia page.

KornShell (ksh) redirection

I have a script which redirects std out/std err as below:
SCRIPTS=/test/scripts
LOG=/test/log
echo $SCRIPTS
echo $LOG
$SCRIPTS/dmm_algo_ofac_daily_sched.ksh >> $LOG/test12.log 2>&1
This script is not able to expand $SCRIPTS and $LOG
If I replace it as below:
/test/scripts/daily_sched.ksh >> /test/log/test12.log 2>&1
It complains as below:
: bad file unit numberd/test.ksh: line 33: 1
Also I am not able to invoke the script from the directory where it is saved. If I do
./test.ksh it gives me error saying file not found. I am able to execute it via ksh /test/sched/test.ksh though.
Can someone help me with these. Thanks in advance.
I'm almost certain that the problem is because of DOS/Windows line endings
The error message you are getting is overwriting itself because of a carriage return. You can fix your file using dos2unix.
Add magic #!/bin/ksh to the first line to invoke directly without naming the interpreter on the command line.
I'll conjecture wildly that your root cause(s) has (have) nothing to do with redirection.
Is the script you've exhibited /test/sched/test.ksh or /test/scripts/test.ksh? Are you certain?

Resources