bad interpreter when running `dirname $0` in sh script

[mozkill]

Can anyone help me explain this issue?

I tried moving a working script from one SUSE linux system to another and now it crashes on this line:

olx8:/usr/odir # more test.sh
#!/bin/sh

DIRNAME=`dirname $0`

olx8:/usr/odir # ./test.sh
: bad interpreter: No such file or directory
olx8:/usr/odir # which sh
/bin/sh

[wje_lf]

To help narrow this down, what is the output when you do these two commands?

which bash
od -t x1 test.sh

[Franklin52]

I'm afraid you have some wrong characters in your script. Does the lines end with CR/LF?
This can happen if you moved the scripts with ftp with a wrong mode (to Windows and back to Linux).

Regards

[wje_lf]

Yes, that's what I'm expecting. But I'm hoping he can do the od and post the results so I can show him a little bit about the ASCII character set.

[mozkill]

thanks SO much guys for helping me....

here is what I get on that:

olx8:/usr/odir # od -t x1 test.sh
0000000 23 21 2f 62 69 6e 2f 73 68 0d 0a 0d 0a 44 49 52
0000020 4e 41 4d 45 3d 60 64 69 72 6e 61 6d 65 20 24 30
0000040 60 0d 0a 0d 0a
0000045
olx8:/usr/odir # which bash
/bin/bash
olx8:/usr/odir #

[mozkill]

ahhh! thanks you guys! typing "dos2unix test.sh" seems to have fixed it.

thank you sooo much!

[wje_lf]

0000000 23 21 2f 62 69 6e 2f 73 68 0d 0a 0d 0a 44 49 52
0000020 4e 41 4d 45 3d 60 64 69 72 6e 61 6d 65 20 24 30
0000040 60 0d 0a 0d 0a
0000045

The 0d is the "return" or "carriage return" character. In the old days of teletypes, that character would cause the print element to return to the left edge of the paper. In the even older days when print elements stood still and the paper moved, the carriage which held the paper would move to the right. That's where the "C" in "CR" comes from.

But that didn't move the paper to the next line. Oh, no, that would be too simple. For that, you needed 0a, which is the "line feed" character. It would feed the paper forward for the distance of one line.

These days, Microsoft-compatible text files use <CR><LF> to mean end of line, as in your original troublesome file. UNIX and friends use <LF> only, I guess on the theory that it's easier to deal with one end of line character than two. (So this left the extra <CR> in your file as (supposed) real data, to fret over.) And Macintosh uses <CR> only.

Go figure.

[drl]

Hi.

... And Macintosh uses <CR> only.

Go figure.

Yes, but that was then -- OS 9 and prior. This is now and for OS X we find:

uname -prs
Darwin 7.9.0 powerpc
echo hi | hexdump -C
00000000  68 69 0a                                          |hi.|
00000003

But I would agree that one might need to be careful of a file that came from a Mac ... cheers, drl

[wje_lf]

Oooo, thanks for the update! I have a question, then.

Suppose you have an old-style text file. Will OS X read it properly? What about a <CR><LF> type file: Will OS X read that properly? How about OS 9?

[drl]

Hi, Bill.

Those situations are why I keep this around:

% convert
convert file contents by one of the following methods:
  addcr - adds a carriage return (^M) in front of every line feed (^J)
  delbs - deletes backspaces and bold or underline characters
  delcr - deletes carriage returns from file
  delff - deletes form feeds from file
  b2ul  - converts boldface text in nroff output to underlined
  cr2lf - converts carriage returns to line feeds
  lf2cr - converts line feeds to carriage returns
  indent - indents text 5 spaces
  sp2tab - converts spaces to tabs via "unexpand"

OS X is unix, for all practical purposes, at the command line ... cheers, drl