Bash script OS detect and if and wget problem. I tried os bit detect itself and it work normaly.
Edit: I found that was space after every "fi"
Ful bash http://pastebin.com/ENVYmXsU
But now i get unexpected end of file.
Edit: I copied same text from pastebin i copied to pastebin and now it works. How is that possible ? Pastebin add extra empty lines This is orig file http://www57.zippyshare.com/v/15049778/file.html
I keep getting
[root#localhost ~]# sh ioncube.sh
: command not found
ioncube.sh: line 28: syntax error near unexpected token `fi'
'oncube.sh: line 28: `fi
The code:
if [ `getconf LONG_BIT` = "64" ]
then
# 64-bit stuff here
wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
else
# 32-bit stuff here
wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz
fi
I think we would need to see line 28 of the script; as that's where the error occurred; you have only posted 14 lines, and which comprise only a single control statement and two commands. FWIW, that code looks' like it should run, although you may wish to put the URI's in "quotes", incase they contain unusual characters.
You must have had Windows newlines in the file. It's a common problem when using Windows editors for *nix shell scripts. – l0b0
Related
A formely working bash script no longer works after switching computers. I get the following error:
No such file or directory.
Before going on, please excuse any mistakes you may find since english is not my native language.
The script was used in cygwin under Windows XP. I now had to switch to cygwin64 under Windwos 7 (64bit).
The script is used as a checkhandler for the program SMSTools3 to split a file with a specific format into multiple smaller ones, which the program then uses to send SMS to multiple recipients. The script was copied directly from the page of SMSTools3 and uses the package formail.
After looking up the error the most likely problem was that the environmantle path was not set up to look in the right path (/usr/bin). I therefore added it to the path but to no avail.
I then deleted other entries in the enviromental path of windows which contained spaces because that could have been another explanation, but again to no avail.
Following is a minimal example of the code which produces the error.
#!/bin/bash
# Sample script to allow multiple recipients in one message file.
# Define this script as a checkhandler.
echo $PATH
which formail
outgoing="/var/spool/sms/outgoing"
recipients=`formail -zx "To:" < "$1"`
I added the lines the lines echo $Path and which formail to show if the script can find the correct file. Both results look fine, the second command gives me the right output '/usr/bin/formail'
But the line recipients=... throws me the error:
No such file or directory.
I do not have much experience with bash scripting, or cygwin in general. So if someone on this wonderful board could help me solve this problem, I would be really grateful. Thank you all for your help.
EDIT:
First of all thank you all for your comments.
Secondly, I would like to apologize for the late reply. The computer in question is also used for other purposes and my problem is part of a background routine, so I have to wait for "free time" on the pc to test things.
For the things #shellter pruposed: The ls command returned an error: '': No such file or directory.
The which -a formail as well as the echo $(which -a formail) commands that #DougHenderson pruposed returned the 'right' path of /usr/bin/formail. echo \$1 = $1 before the recipent line returned the path to the checkhandler file (/usr/local/bin/smsd_checkhandler.sh), the same command after the recipent line seems to show a empty string ($1 = ). Also, the pruposed change to the recipent line did not change the error.
For the dos2unix conversion that #DennisWilliamson pruposed, I opened the file in notepad++ to use their build in converion, but it showed me that the file is in unix format with Unix style line endings.
Running MacOS High Sierra 10.13.5
Good day! Today I attempted to write a script in my .bash_profile to allow me to call Sublime Text with a single command, sublime.
Here is the script I produced with my limited knowledge of bash as well as some research:
sublime_open() # Function which opens the first argument as a text file in Sublime.
{
open -a /Applications/Sublime\ Text.app < $1.txt;
}
export -f sublime_open;
sublime_test() # Function which will open first argument as a text file in Sublime,
{ # creating one if it does not exist in the current directory.
if [ -e "$1" ];
then sublime_open "$1"
else
touch "$1".txt
sublime_open("$1")
fi
}
export -f sublime_test
alias sublime="sublime_test"
export sublime
I separated the function into two pieces for the sake of readability.
Expected Behavior:
sublime foo opens an instance of Sublime to the file foo.txt, creating that file if it does not already exist.
Observed Behavior:
Bash returns:
line 29: syntax error: unexpected end of file
Note that line 29 is the line after the file's final line, which does not exist.
Attempts at solution:
So far I have searched for solutions here and here.
I have tried:
Copying over to a new bash profile and deleting the old one to remove "ghost" characters
Running dos2unix on my .bash_profile
Parsing the script myself looking for individual errors, the problem seems to occur in the sublime_open() portion.
Sorry if my script is elementary or uninformed, this was my first attempt at writing a script that behaves this way. I welcome help or tips outside of the scope of my issue.
Thanks in advance!
Edit: Fixed misused heredoc as per #jwodder's solution as well as improper function calls as per #codeforester's solution.
Edit 2: If you are looking for a more elegant solution to this same problem, have a look at this very helpful gist.
The problem is this line:
open -a /Applications/Sublime\ Text.app << $1.txt;
I assume that what you mean for this to do is to feed the contents of $1.txt to Sublime Text on standard input. However, that would be done with one <, not two. With two <, you get a heredoc, which means that bash will look for the next line containing just $1.txt and will use all lines in between as the input to Sublime Text. As the file ends before bash finds a line with just $1.txt, you get an "unexpected end of file" error.
Keep in mind that on macOS, an *.app is just a folder. Generally speaking, you need to specify the location to a binary (or script). In the case of Sublime Text you have to use the Sublime Text CLI tool:
/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl
See the OS X Command Line documentation for details.
I have a problem with running script under bash. When the script is started and while it is executing some long operation and I change that script, after long operation is finished bash is reading rest of the script and fails with silly errors like below:
test.sh: line 1093: unexpected EOF while looking for matching `"'
test.sh: line 1098: syntax error: unexpected end of file
If I run the same script (without further changes) there are no error whatsoever.
I suspect there is a buffered reading done by bash. Is there something I can do to make bash reading script in whole?
Bash reads the script line by line. If you change the length of a line that's before the current position, bash will start reading the next line from the middle of a line and most probably fail.
Don't change the source of a running script, make a copy.
Probable duplicate of the question asked:
Edit shell script while it's running
In particular, I like the answer at the comment referenced in the link (involves use of the source command and seperate .sh files).
I found a solution: to add {} like
#!/bin/bash
{
code goes here
}
This way everything inside {} will be read into memory.
When running bash scripts in cygwin from the Windows command prompt, I always get a error on line 1, even when the script runs correctly
C:\ImageMagickWatchFolder>bash .\whitebalance
.\whitebalance: line 1: #!/bin/bash: No such file or directory
... (rest of script output)
(whitebalance is the filename of the script)
I've tried replacing line 1 of the script with
#!/cygdrive/c/cygwin64/bash
#!bash
#!C:\cygwin64\bin\bash
#!C:\\cygwin64\\bin\\bash
among others, and just eliminating it entirely, all to no avail. (Some give No such file or directory and some give command not found). In particular, with first line empty, it gives
C:\ImageMagickWatchFolder>bash .\whitebalance
.\whitebalance: line 1: $'\357\273\277': command not found
I also tried switching line ending styles from unix to windows but that just made things worse.
To the first comment below:
C:\ImageMagickWatchFolder>head -n 2 whitebalance | cat -A
M-oM-;M-?#!/bin/bash$
coords=""$
Figured it out. I had been saving the script in Notepad++ in UTF-8-BOM encoding. When changed to UTF-8 or ANSI, the error no longer occurred.
It's impossible to tell from here, but one common way this happens is because of line endings. Make sure your script does not have \r\n (Windows-style) line endings. bash will ignore these but the shebang will still not work: it will try to find /bin/bash\r, and fail.
I'm trying to write a script that contains this
screen -S demo -d -m which should start a new screen session named demo and detach it.
Putting screen -S demo -d -m in the command line works.
If I put it in a file named boot.sh, and run it ./boot.sh I get
Error: Unknown option m
Why does this work in the command line but not as a shell script?
This file was transferred from windows and had ctrl-M characters.
Running "screen" on my Linux machine, a bad option (Screen version 4.00.03jw4 (FAU) 2-May-06) gives the error,
Error: Unknown option -z"
while your description includes no dash before the offending option. I'd check that the characters in your script file are what you expect them to be. There are many characters that look like a dash but which are not.
cat -v boot.sh
may show something interesting as it'll show codes for non-ascii characters.
This may seem a little like the "make sure your printer is plugged in" kind of help, but anyway:
have you tried to check if the screen you're invoking from the script is the same as the one invoked from the command line ?
I'm thinking you may change the PATH variable inside your script somewhere and perhaps screen from the script would be something else (a different version, perhaps ?).