bad interpreter: No such file or directory
 

i downloaded this script from "sourceforge.net/projects/automysqlbackup/" so i could backup my database everyday via a cron. (it wont let me post a url)

however, when time comes around to run the script i get a "bad interpreter: No such file or directorySQL_Backups/cron/mysqlbackup.sh: /bin/bash"

any help would be greatly appreciated. i'm pulling my hairout over this problem!!!

If you open up the script, it will probably have this as the first line:

#!/bin/bash

That line tells the system that /bin/bash should be used to interpret the commands within the file. /bin/bash is the absolute path to the interpreter. It sounds as though you do not have the bash shell installed. If that is the case, then you'll need to install bash, or look for the same (or similar script) written for a shell/language you have installed on your system.

it is also possible, that the partition, where the script is stored and from where you tried to run it, is mounted in a way that makes it impossible for bash to execute the script from there.
So, please check, on which partition you mounted the directory "SQL_Backups/cron/" is on and issue the command "mount" which will show you what is mounted where and with which permissions...

Are you sure, you called the script correctly? To call it from the directory it is in:
change your working directory to there (cd /to/your/directory) and execute it like:
"./your_script" - the script will have to be executable for this to work
"sh -x ./your_script" if it is not executable

You might want to check the file format of the script.
I ran into the same problem. It turned out I need to convert the script from dos format to unix. You can search for dos2unix.pl and download it.

The partition thing is wierd - that's very likely not the problem. XunXu has at least a solution that I have found each and every time this has happened to me - run dos2unix <filename> and it will likely work fine. If you bypass the #!/bin/bash and simply type "bash <filename>" and it still doesn't work then it's the dos2unix thing - I'd bet my 11th toe on it if I had one.

shell does not like CR/LF, if you created your scripot in Windows and transferred it into Linux machine then you have CR/LFs in you shell script that you have to remove. KWrite has an option to replace CR/LFs with CRs.

Easy fix specifically for this script
 

I down loaded the same file and had the same problem. I found this fix on the web:

mv file.txt file.bak; tr -d '\r' < file.bak > file.txt

It makes a backup file then uses the translate command to delete the <CR> from the file and outputs the fixed file. Once I did this to the automysqlbackup.sh run without that error on
SuSE 9.2 Linux

found it at: http://db.ilug-bom.org.in/Documentat...e-HOWTO-5.html

i've had the same problem, but i wrote my script entirely on my linux, using vi. so, how could that happen? :confused:

Depending on the vi clone you are using, the carriage return may or may not be displayed. To be sure, run:
and check if the output looks like

I have run into this problem many times when editing scripts on a windows based system then FTP'ing them onto my servers. I simple Perl command always seems to clear up the problem. Try the following command on your text file then try and run it.

perl -i -pe's/\r$//;' <file name here>

wbrummet, you're definetly the boss!

Thanks, it helped me a lot! :D

In Kate: load file -> main menu -> Preferences -> Line Ends (or some such) -> tick unix -> save ;).

<edit aug.31> No. That definitely doesn't do the trick. See:

http://www.linuxquestions.org/questi...93#post2872993 </edit>

Just a few remarks:

A lot of the commands (using tr, perl, ...) posted here all do pretty much the same as the "dos2unix" utility mentioned. Please use this utility, as it was specifically created for this CR\LF issue.

@batch52: "tr" is short for "transliterate", not "translate".

When transferring scripts and other text files from Windows to Linux or vice-versa via FTP, please use "ascii" transfer mode, not binary. This will automatically correct for the CR/LF issue.

If you edit a file in vi or vim, watch out for the small mark "[dos]" at the bottom, which tells you if the text file has DOS-styl line endings (\n\r) rather than Linux style ones. vi/vim has a command to switch from one style to the other as well.

Put this in .vimrc

" Add keymappings
map <F4> :set fileformat=unix<CR>
map <F5> :set fileformat=dos<CR>

Then use F4/F5 for changing fileformat

bad interpreter: No such file or directory