OS: SLES9 I have been moving some accounting software from a SCO server to SLES9 but have run into a problem that has me stumped: a shell script calling programs in the same directory keeps giving me errors like: script_name: Line xx: program: No such file or directory I have added the current directory (.) to the PATH, made sure the programs are executable and even checked the file type (ELF 32-Bit LSB Executable Intel 80386 Version 1 (SYSV), dynamically linked (uses shared libs), stripped). Oh yes, I can list the programs just fine. I have tried changing ownership, using full (777) permissions, executing as root, adding the full path name, all to no avail. I get a similar error when attempting to execute the invoked programs direct from the command line, except the error line starts with "-bash:". Is there something I am overlooking here? FWIW, this is an AcuCOBOL application. Please Help! Thank you, Lucky Leavell
On Thursday 09 March 2006 22:28, Lucky Leavell wrote:
Is there something I am overlooking here?
Hi Lucky, I had a similar experience once and it turned out the binaries had paths hard coded in. What threw me at first was the error message *seemed* to be saying the program, itself, couldn't be found. Instead, bash was feeding the error message "No such file or directory" back to me *on behalf of* the program. IIRC, that software couldn't be moved to another machine without being recompiled. :-/ I don't know if this is the situation you're in, but it would explain a lot. Have you tried a "--verbose" or "-V" on any of the programs? What about an strace? Carl
On Thursday 09 March 2006 22:28, Lucky Leavell wrote:
Is there something I am overlooking here?
As a matter of fact, I was overlooking something, or, rather, was given erroneous information. The application's salesperson told me the AcuCOBOL runtimes were the same for SCO OpenServer and Linux which sounded fishy but ... I finally got a call back from one of their tech support people who informed me the run times were most certainly different and went through the suggested procedures for the platform change. I did so and everything is working now. Thanks for all the suggestions from all who responded. I certainly do not regret the choice of SLES9 as a replacement platform for SCO. Thank you, Lucky
Lucky, On Thursday 09 March 2006 19:28, Lucky Leavell wrote:
OS: SLES9
I have been moving some accounting software from a SCO server to SLES9 but have run into a problem that has me stumped: a shell script calling programs in the same directory keeps giving me errors like:
script_name: Line xx: program: No such file or directory
...
Is there something I am overlooking here?
There may be unsatisfied dynamic link library requirements. Run "ldd" on the program that appears not to be found and verify that all its dynamic library dependencies are met.
... Lucky Leavell
Randall Schulz
On Thu, 9 Mar 2006, Randall R Schulz wrote:
Lucky,
There may be unsatisfied dynamic link library requirements. Run "ldd" on the program that appears not to be found and verify that all its dynamic library dependencies are met.
Here are the results of a ssh session first attempting to execute the script and then attempting to run strace and ldd on the acushare executable. The runrw32 script invokes the run32 script which in turn invokes acushare and runcbl. I added an "echo $PATH" at the top of the run32 script and also show the listing of both acushare and runcbl in the /rwc/rw32 directory: lucky@sles9:~> runrw32 .:/home/lucky/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin ./run32: line 47: ./acushare: No such file or directory ./run32: line 60: ./runcbl: No such file or directory lucky@sles9:~> cd /rwc/rw32 lucky@sles9:/rwc/rw32> l acushare -rwxrwxrwx 1 terry users 175724 2005-12-08 13:01 acushare* lucky@sles9:/rwc/rw32> l runcbl -rwxrwxrwx 1 terry users 1785744 2005-05-13 13:56 runcbl* lucky@sles9:/rwc/rw32> strace acushare -start strace: acushare: command not found lucky@sles9:/rwc/rw32> ldd acushare /usr/bin/ldd: line 1: ./acushare: No such file or directory At this point I am tempted to install the /rwc/rw32 directory on my 32-bit SuSE 10 system to try to see if there may be a difference between 32-bit and 64-bit. As always, HELP and thank you, Lucky
On Friday 10 March 2006 15:09, Lucky Leavell wrote:
lucky@sles9:~> runrw32 .:/home/lucky/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/o pt/gnome/bin:/opt/kde3/bin ./run32: line 47: ./acushare: No such file or directory ./run32: line 60: ./runcbl: No such file or directory lucky@sles9:~> cd /rwc/rw32 lucky@sles9:/rwc/rw32> l acushare -rwxrwxrwx 1 terry users 175724 2005-12-08 13:01 acushare* lucky@sles9:/rwc/rw32> l runcbl -rwxrwxrwx 1 terry users 1785744 2005-05-13 13:56 runcbl* lucky@sles9:/rwc/rw32> strace acushare -start strace: acushare: command not found lucky@sles9:/rwc/rw32> ldd acushare /usr/bin/ldd: line 1: ./acushare: No such file or directory
Your script executes ./acushare, which means you need to be in /rwc/rw32 when you run it (or you need to have a cd to that directory before the command gets run) Is any partition on your system mounted noexec? What do you get if you run file /rwc/rw32/acushare -- Certified: Yes. Certifiable: of course! jabberID: anders@rydsbo.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-03-10 at 09:09 -0500, Lucky Leavell wrote:
Here are the results of a ssh session first attempting to execute the script and then attempting to run strace and ldd on the acushare executable. The runrw32 script invokes the run32 script which in turn invokes acushare and runcbl. I added an "echo $PATH" at the top of the run32 script and also show the listing of both acushare and runcbl in the /rwc/rw32 directory: lucky@sles9:~> runrw32 .:/home/lucky/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin
Only the programs that are in on of those directories will get executed, and acushare and runcbl are not there.
./run32: line 47: ./acushare: No such file or directory ./run32: line 60: ./runcbl: No such file or directory
lucky@sles9:~> cd /rwc/rw32 lucky@sles9:/rwc/rw32> l acushare -rwxrwxrwx 1 terry users 175724 2005-12-08 13:01 acushare*
Probably changing to this directory prior to running the script would work
lucky@sles9:/rwc/rw32> strace acushare -start strace: acushare: command not found
Of course, as "./" is not in the path, you have to explitly call it ./acushare. And it is a bad idea to add "./" to the path (security risk). - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEEvIytTMYHG2NR9URAqZlAJ40c8pQDbwTRYyT+qY5KgQa+ZLyLQCfXfH2 65PJsZjZmUtHOK4X5jH2mMM= =ioyH -----END PGP SIGNATURE-----
On Saturday 11 March 2006 16:52, Carlos E. R. wrote:
.:/home/lucky/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games: <snip> Of course, as "./" is not in the path, you have to explitly call it
Looks to me like it's first in there. Am I missing something? -- Certified: Yes. Certifiable: of course! jabberID: anders@rydsbo.net
On Sat, 2006-03-11 at 16:53 +0100, Anders Johansson wrote:
On Saturday 11 March 2006 16:52, Carlos E. R. wrote:
.:/home/lucky/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games: ^
<snip>
Of course, as "./" is not in the path, you have to explitly call it
Looks to me like it's first in there. Am I missing something?
I would agree it is the first entry in this persons path. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-03-11 at 11:32 -0500, Ken Schneider wrote:
Looks to me like it's first in there. Am I missing something?
I would agree it is the first entry in this persons path.
True enough. I would, anyway, include "/rwc/rw32" in the path explictly. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEExA3tTMYHG2NR9URAmszAJ9vKQmHsoDwHfaas+cmNj1DUsrl8ACffBFL R743ZF6LxG7sL0OfRBMOtoM= =bidg -----END PGP SIGNATURE-----
Additional Information: This is an Intel EM64T system (IBM eSeries 206) with the 64-bit version of SLES9, not the 32-bit. When attempting to create the Rescue Ranger (LoneTAR) recovery media, I had an error stating it could not copy /usr/lib64/libcrypto.so.0.9.7 though the file does exist with that path. Are there known problems with the 64-bit version of SLES9 in this regard? Can I use the 32-bit version on EM64T hardware (which would allow use of the Adaptec hardware RAID driver which is only currently available for 32-bit SLES9, not 64-bit)? Thank you, Lucky Leavell
participants (6)
-
Anders Johansson -
Carl Hartung -
Carlos E. R. -
Ken Schneider -
Lucky Leavell -
Randall R Schulz