views:

208

answers:

5

Question: I get this error message:

export: bad interpreter: No such file or directory

when I execute this bash script:

#!/bin/bash
MONO_PREFIX=/opt/mono-2.6
GNOME_PREFIX=/opt/gnome-2.6
export DYLD_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
PATH=$MONO_PREFIX/bin:$PATH
PS1="[mono-2.6] \w @ "

But the bash path seems to be correct:

asshat@IS1300:~/sources/mono-2.6# which bash
/bin/bash

asshat@IS1300:~# cd sources/
asshat@IS1300:~/sources# cd mono-2.6/
asshat@IS1300:~/sources/mono-2.6# ./mono-2.6-environment
export: bad interpreter: No such file or directory
asshat@IS1300:~/sources/mono-2.6# ls
download  mono-2.4  mono-2.4-environment  mono-2.6  mono-2.6-environment
asshat@IS1300:~/sources/mono-2.6# cp mono-2.6-environment mono-2.6-environment.sh
asshat@IS1300:~/sources/mono-2.6# ./mono-2.6-environment.sh
export: bad interpreter: No such file or directory
asshat@IS1300:~/sources/mono-2.6# ls
download  mono-2.4-environment  mono-2.6-environment
mono-2.4  mono-2.6              mono-2.6-environment.sh
asshat@IS1300:~/sources/mono-2.6# bash mono-2.6-environment
asshat@IS1300:~/sources/mono-2.6#

What am I doing wrong? Or is this a Lucid bug?

I did chmod + x

+6  A: 

The first line: #!/bin/bash

Tells linux where to find the interpreter.

It is highly likely that you created this file with a windows editor, which will place a <cr><lf> at the end of each line. This is the standard under dos / windows. However, under Unix / linux, the standard is to just put a <lf> at the end of the line.

Linux is now looking for a file called /bin/bash<cr> to interpret the file, where <cr> is a carriage return character, which is a valid file character under linux. Such a file doesn't exist. Hence the error.

Solution: Edit the file with an editor on linux and get rid of the extra <cr>.

Matthias Wandel
Partially wrong. I haven't created it on Windows, I used cat > filename. dos2unix doesn't make it work either, but gvim shows some unusual characters. I copy pasted to a new file - without changes, and it begun working immediately...
Quandary
Note, I believe nano, emacs and vi will _automagically_ strip that. All the OP has to do is open and save it with any of the above.
Tim Post
@Quandary, using _what_ ssh / terminal client did you create this file? What terminal type? I have not seen this kind of problem since Novell Virtual Terminal and 3270 environments. What, exactly did you use to create the file, beyond `cat` ? Maybe you are using a brain dead serial -> TCP/IP adapter?
Tim Post
Nope, it was the bash shell @localhost
Quandary
+2  A: 

Could the script be using Dos newlines?

Try running dos2unix on it.

Anton
No it's not, I already runned tofrodos. The problem were some other characters, apart from \r\n. Strange...
Quandary
A: 

Did you run it like this (you did mention chmod +x)

. /path/to/it

or like this:

./it

?

I have a sneaking suspicion that your code executed in a new process, and everything you told it was lost. Hence, variables will not be expanded in your current shell. However, this does not explain the bad interpreter error that you saw. I think you also have a terminal problem (as in terminal, what you used to talk to cat).

The fact that your prompt did not do what this said:

`PS1="[mono-2.6] \w @` "

Makes me think you ran, not sourced the code. There is a difference. I could not get what you posted to break.

Tim Post
A: 

Had the same problem. Used brute force:

/bin/sh /full/path/to/configure --options

& this did the trick

(Of course I'd like to know why)

pol
A: 

It looks like things have been configured to override the export builtin somehow. This can be done via an exported function or the enable builtin, for example. Try putting type export in the script to check. If you are setting BASH_ENV, you probably shouldn't.

If bash is called as sh, it enables POSIX mode and does not allow export to be overridden with a function, as required by POSIX. Likewise, most other shells installed as /bin/sh follow POSIX in this and/or do not allow the execution environment of a script to be messed up so strongly as through importing functions from the environment.

By the way, the script seems designed to be sourced, i.e. . ./mono-2.6-environment instead of ./mono-2.6-environment.

jilles