I have 2 linux servers:

OLD OS: RedHat GNU/Linux 2.4.21-58.ELsmp (i686/i386), A NewTech machine
NEW OS: RedHat GNU/Linux 2.6.18-128.1.16.el5 (x86_64/x86_64), A Dell machine

I installed a SmartList package on the old server, it worked
perfectly fine. But on the new server, when I do:

> sh install.sh /usr/local/slist

- this generates endlessly the following line:
"install.sh3: line 3: cd: .: Not a directory"
...

that took 99% of one CPU and eventually I had to kill it.

I don't think it's the install scripts problem. Anything occur to you that I may need to look into?

Joe

Did you check to see what is on line 3 of the install.sh3 (or install.sh)?

My guess is the directory it is trying to cd to is a variable (e.g. $DIR) and it didn't get set properly. Are you supposed to input a directory? Is it setting it with pwd?

By the way - The info you provided is kernel versions. The actual RedHat versions can be found in /etc/redhat-release.

There are significant changes between the 2.4.x kernels and the 2.6.x kernels. Things that worked on 2.4.x might not work on 2.6.x if they're not written to be portable. Many applications have separate install scripts for 2.4.x (up to RHEL3) and 2.6.x (RHEL 4 and beyond).

First 3 lines of "install.sh":
#! /bin/sh
: &&O='cd .' || exec /bin/sh "$0" $argv:q
$O || exec /bin/sh "$0" "$@"

First 3 lines of "install.sh3":
#! /bin/sh
: &&O='cd .' || exec /bin/sh install.sh3
$O || exec /bin/sh install.sh3

-- There is a "cd . " on line 2, not line 3.
It's beyond me... Any further insight?

Thank you,
Joe

The error says "." (dot) is not a directory. Since "." is the link for the current directory in any directory you're in this shouldn't be the case. I have seen on rare occasion the "." (or ".." for parent directory) somehow go missing. This is usually a sign of something having gone horribly wrong.

Try running "ls -la" in the directory you attempted this in and see if the "." and ".." files are there. Then try running "cd ." to see what happens. Try running "ls -id ." to get the inode number then run "ls -id <fullpath to directory> to insure they have the same inode number.

o "." and ".." is always there in the current and other dirs.
o "cd . " -- nothing happens (expected).
o "ls -id ." and "ls -id /full/path/to'.'" give the same inode number ("68304901" in this case). I tested on a few related directories, the inode numbers are consistently the same from "." and "/full/path/" (different dir has different numbers).

... I am still in mist. Further suggestion?

Joe

Since the error is coming out of install.sh3 it might be worthwhile to temporarily change the interpreter line in install.sh3 to "#!/bin/sh -x" so it runs in debug mode. That way you'd see what it was doing up to the point of failure.

I'm assuming that install.sh is calling install.sh3 so if setting debug in the latter doesn't help it might be worthwhile to try setting it in the former.

Thank you.

I put debug bit "#!/bin/sh -x" in either or both, all show the following:

make: `gethome' is up to date.
Hardwiring '$HOME' as the list directory owned by 'slist'.
make: `multigram' is up to date.
/bin/sh: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
(... repeat this line endlessly ...)

Note: in "sh install.sh /usr/local/slist", the path fed to the install script is the $HOME of 'slist'.

What to try next? (Thank you for your patience for newbie like me

Joe

It might be a nesting issue. Since install.sh and install.sh3 both have interpreter lines they're each invoking subshells. However you started with "sh" so by the time it gets to install.sh3 it is at least in its 3rd subshell (perhaps more if there were other things invoked like install.sh2).

Try running just ./install.sh <direcory> instead of sh install.sh <directory> to see if it makes a difference. If it says not executable you can make it so with the chmod command.

Here is what I tried:

First I commented out the trouble line in 'install.sh3':

# : &&O='cd .' || exec /bin/sh install.sh3

-- Now the install proceeded but ended up with the target location having a bunch of missing directories/files (not installed).

Next, I tried to put the target dir path for that 'cd', as in:

: &&O='cd /usr/local/slist' || exec /bin/sh install.sh3

-- Now it complains it cannot find a file "targetdir.tmp" which I see is in the source dir.

Therefore I put the source path for 'cd', as in:

: &&O='cd /data/procmail-3.15/SmartList' || exec /bin/sh install.sh3

or

: &&O='cd /data/procmail-3.15/SmartList/' || exec /bin/sh install.sh3

-- in both cases I got errors:

------------------------------------------------
install.sh3: line 4: cd: /data/procmail-3.15/SmartList: Not a directory
------------------------------------------------

-- which is the same error originally observed. Through the trials
I made sure my shell is '/bin/sh'. I also manually tried
"cd /data/procmail-3.15/SmartList" that works well. Just don't understand why in the script it got that complain...

-- Recall that it works no problem on an older version of RH linux.

Run by "sh install.sh ..." or "./install.sh ..." have the same behavior.

Joe

Check to see what /bin/sh is linked to in the older version and the newer version. Typically it is /bin/bash but this may be the crux of the problem if one has /bin/bash and the other has /bin/zsh (or one has /bin/ksh and the other has /bin/bash).

sh was the original Bourne Shell (on HP-UX however it is the Posix Shell which is more like ksh).
ksh was Korn Shell which had many enhancements over Bourne.
bash is Bourne Again Shell and has even more enhancements.

To make things even more fun there are different versions of the above. For example on RHEL4 one had to use pdksh to get ksh whereas on RHEL5 there is a more posix compliant ksh and I've found a couple of differences between them.

They are all linked to 'bash':

On the old machine:
GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
585908 bytes

On the new machine:
GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
801512 bytes

I was bold enough to try this: Copy over the /bin/bash file from the old machine (it didn't complain "architecture" problem or else upon trial), and used it to do the "install" - it produces the same error ("Not a directory"). I suppose it's from the lib of (ba)sh on the system?

Looks like there won't be any easy fix for my problem at this point..

Perhaps this worthies to be registered for developers?

Joe