odd shell script link errorsafter login procedure update

[Lynne Seamans]

WE've started getting odd errors running some shell scripts. THe only change to the system had been in an application, and some of the scripts that are called by our users .profile. No patches or anything else.

I have no idea what the errors mean. Yeah, /bin/sh and /usr/bin/sh are hard linked, they have the same inode. That's the way it's supposed to be!

Here's what we're seeing:

interpreter "/bin/sh" not found
file link resolves to "/usr/bin/sh"

[A. Clay Stephenson]

Taking you at your word that NOTHING has changed other than the application and scripts, I'll take a couple of WAG's:

1) Your scripts were copied/ftp'ed from a Windows box and have CR/LF in them rather than just LF's. Run then through dos2ux to clean that up or ftp them in ASCII mode.

2) Your application did a chroot().

[Lynne Seamans]

These scripts have worked on this hp-ux 11.0 box up until this week, so i don't think the cr/lf idea applies.

BUT, they might call an executable which does a chroot. Where do i go with that?

Thanks for the tip, btw.

[A. Clay Stephenson]

Well, the CR/LF pairs problem would exactly fit your situation and depending upon the text editor you use might not even be apparent. I'd bet on that. In any event, if there is any doubt, make copies of your files and try dos2ux. It does no harm if there are no CR/LF pairs but make sure that the executable bit is set on your output files.

The chroot() is more subtle and the only guys who would know are the developers.

chroot("/home/mydir");
now every reference to "/" would actually refer to "/home/mydir" so that "/bin/sh" would actually be "/home/mydir/bin/sh".

[Steven E. Protter]

Looks like the SHELL in the script or in /etc/passwd is not there or:

the actual /bin/sh shell is not there.

#!/bin/sh

may not be right.

You'd have more trouble if that was the case so check the scripts.

SEP

[Michael Schulte zur Sur]

Hi,

/bin/sh and /usr/bin are not hard linked, they are the same because /bin is a link to /usr/bin.
Please post ls -lisad /bin /bin/sh /usr/bin/sh

thanks,

Michael

[Bill Hassell]

Just edit one of the problem scripts and see if there are ^M characters. If not, make sure the FIRST line of ALL your scripts is #!/usr/bin/sh or perhaps #!/usr/bin/ksh (/bin/sh and /bin/ksh have been deprecated for almost 10 years). Note that if the scripts do not start with #!/usr/bin/sh, then whatever shell you are running will attempt to interpret your script. If that checks out, then create a simple script:

#!/usr/bin/sh
PATH=/usr/bin
date

Make this executable and run it. If this works, then check for permission changes made to / /usr /opt /dev /tmp /var. They should look like this:

ll -d / /usr /opt /dev /tmp /var
drwxr-xr-x 20 root root 8192 Feb 24 22:03 //
dr-xr-xr-x 16 bin bin 8192 Feb 18 13:26 /dev/
dr-xr-xr-x 50 bin bin 8192 Mar 2 12:00 /opt/
drwxrwxrwt 6 bin bin 8192 Mar 9 02:01 /tmp/
dr-xr-xr-x 25 bin bin 8192 Oct 24 13:07 /usr/
dr-xr-xr-x 26 bin bin 8192 Dec 17 08:23 /var/

[Lynne Seamans]

Wow, thanks for all the help and interest!

(1) Micheal is absolutely correct about the links, and here is the command he asked to see:
ls -lisad /bin /bin/sh /usr/bin/sh
908 0 lr-xr-xr-t 1 root sys 8 Jul 27 2000 /bin -> /usr/bin
19927 424 -r-xr-xr-x 2 bin bin 217088 Jul 1 2003 /bin/sh
19927 424 -r-xr-xr-x 2 bin bin 217088 Jul 1 2003 /usr/bin/sh

(2) The ^M thing sounds possible because some of this was converted from EBCDIC text. Unfortunately, i'm stupid and do not know how to check for a control character using vi. I will if you tell me how :)

[A. Clay Stephenson]

Merely open one of the files with vi.
e.g. vi myfile.sh

If the CR's are in the file, you will see "^M"; ie CR == Control-M == ASCII 13 (dec).

[Bill Hassell]

Sorry, I should have made the vi method more clear. Another way is to use cat -v

[Peter A. Berger Jr.]

All:

I was getting the same error message:
nterpreter "/bin/sh" not found
file link resolves to "/usr/bin/sh"

when I went to run the create_depot command after I downloaded some patches from the ITRC.

I did indeed un-zip them on my XP machine and then SFTP them over to the HP-UX 11.23 box.

Running the command:
dos2ux oldfile > newfile

did the trick and the create_depot command then worked fine.

thanks for the tips. I hope this helps others too. ITRC forums rock!