Hi all.
I have a little strange problem. I created a file called 'test.sh' in the root directory containing: #!/bin/sh echo test
When I execute it with '/test.sh' there is no output. When I source it by executing it with '. /test.sh' the output comes ok. When I move it to '/root' and execute it with '/root/test.sh' then it works perfectly. When I move it to '/home' and execute it with '/home/test.sh' there is no output.
Could someone tell me what I shoud do to make the script run without sourcing it with '.' ? This problem happens only on one CentOS 4 box I have, on the others it works perfectly. What am I doing wrong ? The permissions are 755 on the file itself, and I execute them logged as root.
Thanks, Daniel
On Sun, 2005-07-31 at 15:56 +0200, dan1 wrote:
Hi all.
I have a little strange problem. I created a file called 'test.sh' in the root directory containing: #!/bin/sh echo test
When I execute it with '/test.sh' there is no output. When I source it by executing it with '. /test.sh' the output comes ok. When I move it to '/root' and execute it with '/root/test.sh' then it works perfectly. When I move it to '/home' and execute it with '/home/test.sh' there is no output.
Could someone tell me what I shoud do to make the script run without sourcing it with '.' ? This problem happens only on one CentOS 4 box I have, on the others it works perfectly. What am I doing wrong ? The permissions are 755 on the file itself, and I execute them logged as root.
Thanks, Daniel
Dan,
I can't duplicate your issue ... test.sh prints test on my xterm console every time.
It works whether I use echo test or echo "test" ... and works with #!/bin/sh or #!/bin/bash ... on my CentOS-4 i386 machine.
It also worked for both root and a non-root user.
-- Johnny Hughes
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Sun, 2005-07-31 at 15:56 +0200, dan1 wrote:
Hi all.
I have a little strange problem. I created a file called 'test.sh' in the root directory containing: #!/bin/sh echo test
When I execute it with '/test.sh' there is no output. When I source it by executing it with '. /test.sh' the output comes ok. When I move it to '/root' and execute it with '/root/test.sh' then it works
perfectly. When I move it to '/home' and execute it with '/home/test.sh' there is no output.
Could someone tell me what I shoud do to make the script run without sourcing it with '.' ? This problem happens only on one CentOS 4 box I have, on the others it
works
perfectly. What am I doing wrong ? The permissions are 755 on the file itself, and I execute them logged as root.
Thanks, Daniel
Dan,
I can't duplicate your issue ... test.sh prints test on my xterm console every time.
It works whether I use echo test or echo "test" ... and works with #!/bin/sh or #!/bin/bash ... on my CentOS-4 i386 machine.
It also worked for both root and a non-root user.
-- Johnny Hughes
Does this happen with all the scripts you try to run or just this one?
If it is just with this one, rename it to something like abc.sh and see if it works.
Could be because the shell is getting it confused with the 'test' operator.
On Sunday 31 July 2005 14:16, BRUCE STANLEY wrote:
Does this happen with all the scripts you try to run or just this one?
If it is just with this one, rename it to something like abc.sh and see if it works.
Could be because the shell is getting it confused with the 'test' operator.
And if it happens to all scripts, is your /home partition maybe mounted with the noexec option?
Peter.
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Sun, 2005-07-31 at 15:56 +0200, dan1 wrote:
Hi all.
I have a little strange problem. I created a file called 'test.sh' in the root directory containing: #!/bin/sh echo test
When I execute it with '/test.sh' there is no output. When I source it by executing it with '. /test.sh' the output comes ok. When I move it to '/root' and execute it with '/root/test.sh' then it works
perfectly. When I move it to '/home' and execute it with '/home/test.sh' there is no output.
Could someone tell me what I shoud do to make the script run without sourcing it with '.' ? This problem happens only on one CentOS 4 box I have, on the others it
works
perfectly. What am I doing wrong ? The permissions are 755 on the file itself, and I execute them logged as root.
Thanks, Daniel
Dan,
I can't duplicate your issue ... test.sh prints test on my xterm console every time.
It works whether I use echo test or echo "test" ... and works with #!/bin/sh or #!/bin/bash ... on my CentOS-4 i386 machine.
It also worked for both root and a non-root user.
<> --
Johnny Hughes
Does this happen with all the scripts you try to run or just this one?
If it is just with this one, rename it to something like abc.sh and see if it works.
Could be because the shell is getting it confused with the 'test' operator.
Hello all.
Thanks for your try to help me, Johnny, Peter and Bruce.
Yes, this happens with almost all scripts. However I don't think that this is related to the PATH, because I can even access the file directly with it's path like '/test.sh' and the problem is the same. I also renamed the file and this doesn't change anything to the problem neither.
On one script that I have, it went differently:
[root@box scripts]# ./get_ipaddress bash: ./get_ipaddress: bin/sh: bad interpreter: No such file or directory [root@box scripts]# sh ./get_ipaddress 154.37.1.234 [root@box scripts]#
This script is the following:
#!bin/sh CURRENT_IP=`/sbin/ifconfig eth0 | grep inet | cut -d : -f 2 | cut -d \ -f 1` export CURRENT_IP echo $CURRENT_IP
So it's like if it wouldn't find the /bin/sh, because it shows 'bin/sh' instead of '/bin/sh'. Maybe this is the error ? How could I fix it then ? I checked in /etc/passwd and the definition under root is '/bin/bash', but I don't think that the interpreter path is read there for running scripts, does anybody know ? And again, this doesn't happen on two other exactly same boxes I have there (so almost, appart of this little misconfiguration)..
My PATH is the following: [root@anoigo bin]# echo $PATH /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/home/dan/bin:/sbin:/usr/sbin
Thanks, Daniel
On Mon, Aug 01, 2005 at 07:39:06PM +0200, dan1 enlightened us:
--- Johnny Hughes mailing-lists@hughesjr.com wrote:
On Sun, 2005-07-31 at 15:56 +0200, dan1 wrote:
Hi all.
I have a little strange problem. I created a file called 'test.sh' in the root directory containing: #!/bin/sh echo test
When I execute it with '/test.sh' there is no output. When I source it by executing it with '. /test.sh' the output comes ok. When I move it to '/root' and execute it with '/root/test.sh' then it works
perfectly. When I move it to '/home' and execute it with '/home/test.sh' there is no output.
Could someone tell me what I shoud do to make the script run without sourcing it with '.' ? This problem happens only on one CentOS 4 box I have, on the others it
works
perfectly. What am I doing wrong ? The permissions are 755 on the file itself, and I execute them logged as root.
Thanks, Daniel
Dan,
I can't duplicate your issue ... test.sh prints test on my xterm console every time.
It works whether I use echo test or echo "test" ... and works with #!/bin/sh or #!/bin/bash ... on my CentOS-4 i386 machine.
It also worked for both root and a non-root user.
<> --
Johnny Hughes
Does this happen with all the scripts you try to run or just this one?
If it is just with this one, rename it to something like abc.sh and see if it works.
Could be because the shell is getting it confused with the 'test' operator.
Hello all.
Thanks for your try to help me, Johnny, Peter and Bruce.
Yes, this happens with almost all scripts. However I don't think that this is related to the PATH, because I can even access the file directly with it's path like '/test.sh' and the problem is the same. I also renamed the file and this doesn't change anything to the problem neither.
On one script that I have, it went differently:
[root@box scripts]# ./get_ipaddress bash: ./get_ipaddress: bin/sh: bad interpreter: No such file or directory [root@box scripts]# sh ./get_ipaddress 154.37.1.234 [root@box scripts]#
This script is the following:
#!bin/sh CURRENT_IP=`/sbin/ifconfig eth0 | grep inet | cut -d : -f 2 | cut -d \ -f 1` export CURRENT_IP echo $CURRENT_IP
You need to change the first line to #!/bin/sh ^
Otherwise, the script is looking for a bin directory in whatever current directory you are in. Unless you are at the root of the filesystem, it most likely won't be found.
Matt
This script is the following:
#!bin/sh CURRENT_IP=`/sbin/ifconfig eth0 | grep inet | cut -d : -f 2 | cut -d -f 1` export CURRENT_IP echo $CURRENT_IP
You need to change the first line to #!/bin/sh
Otherwise, the script is looking for a bin directory in whatever current directory you are in. Unless you are at the root of the filesystem, it most likely won't be found.
Matt
Hello, Matt.
Sorry for that. Yes you are right it is a mistake. However this was only on this script. The problem I described before still remains the same for the other scripts and even on this one once I have corrected it to #!/bin/sh.
There is simply no output at all for those scripts and no error message neither. And it's also strange that it works when put in the /root directory and not in the /. The /root is on the same filesystem than / and I have verified in the /etc/fstab : the / is mounted with the options: defaults,usrquota,grquota. The 'noexec' option is not set.
Any other idea ?
Thanks, Daniel
--- dan1 dan1@edenpics.com wrote:
This script is the following:
#!bin/sh CURRENT_IP=`/sbin/ifconfig eth0 | grep inet | cut -d : -f 2 | cut -d -f 1` export CURRENT_IP echo $CURRENT_IP
You need to change the first line to #!/bin/sh
Otherwise, the script is looking for a bin directory in whatever current directory you are in. Unless you are at the root of the filesystem, it most likely won't be found.
Matt
Hello, Matt.
Sorry for that. Yes you are right it is a mistake. However this was only on this script. The problem I described before still remains the same for the other scripts and even on this one once I have corrected it to #!/bin/sh.
There is simply no output at all for those scripts and no error message neither. And it's also strange that it works when put in the /root directory and not in the /. The /root is on the same filesystem than / and I have verified in the /etc/fstab : the / is mounted with the options: defaults,usrquota,grquota. The 'noexec' option is not set.
Any other idea ?
Thanks, Daniel
Hi Dan!
The '/bin/sh' command is usually a symbolic link to '/bin/bash'. Check this by ls -l /bin/sh (should show it pointing to bash).
Maybe the link has gotton broken some how.
Change the '#!/bin/sh' in the scripts to '#!/bin/bash' and see if they then execute ok.
If so, as root, 'rm /bin/sh' , followed by 'ln -s /bin/bash /bin/sh' to fix the link.
Hi Dan!
The '/bin/sh' command is usually a symbolic link to '/bin/bash'. Check this by ls -l /bin/sh (should show it pointing to bash).
Maybe the link has gotton broken some how.
Change the '#!/bin/sh' in the scripts to '#!/bin/bash' and see if
they then execute ok.
If so, as root, 'rm /bin/sh' , followed by 'ln -s /bin/bash /bin/sh' to fix the link.
Hi Bruce.
Good idea.. I tried it also already... unfortunately it's not that. And replacing #!/bin/sh by #!/bin/bash makes the same problem: no output. To try something else, I have written something to a file by the script, to see if this was an display problem, and that the script would print out to somewhere else than to the console output. The file is not written at all, so it's really like if the script would not be executed at all. The output of the execution of any script is the following:
[root@box /]# /test.sh [root@box /]#
So it finds the file, is apparently able to do something with it, but doesn't execute the script nor display any message regarding the problem that occurs.
I also tried to replace the /bin/bash file with another one same version from a CentOS 4 machine on which that problem doesn't occur, and the issue still remains.
That's a tough one, isn't it ? And I'm a bit annoyed because I wouldn't like to re-install everything, I just passed 2-3 days configuring this new server. Appart of that it works great.. As many scripts are calling others without putting the 'sh command' but directly accessing it with it's path, I think that I have to solve that issue before being able to use the server in production, because it might be fatal in a future need of it working properly.
Thanks for all your inputs that I appreciate a lot..
Daniel
Hello all.
To continue with the problem I am facing, I have some news..
When I delete the line #!/bin/sh then the script works perfectly. When I put it again then the problem occurs again. So the script just containing 'echo test' just works fine, but the script: #!/bin/sh echo test
doesn't work (except when put in the /root directory) ... and this is true for all other scripts.
So the question is: does anybody know what program is in charge of parsing that '#!/bin/sh' information, which apparently makes an error in the parsing ? Is there any linux guru that would know of it ?
Thanks, Daniel
On 02/08/05, dan1 dan1@edenpics.com wrote:
So the question is: does anybody know what program is in charge of parsing that '#!/bin/sh' information, which apparently makes an error in the parsing
http://en.wikipedia.org/wiki/Shebang answers that.
The "file" package will certainly be needed for this to function correctly but I imagine your system would be really badly broken without.
<-----------------------------------------------------------------------------------------------------------------> # rpm -qf magic file-4.12-1.FC3.1 # rpm -qi file Name : file Relocations: (not relocatable) Version : 4.12 Vendor: Red Hat, Inc. Release : 1.FC3.1 Build Date: Mon 31 Jan 2005 08:48:36 GMT Install Date: Mon 21 Mar 2005 12:32:19 GMT Build Host: tweety.build.redhat.com Group : Applications/File Source RPM: file-4.12-1.FC3.1.src.rpm Size : 1415765 License: distributable Signature : DSA/SHA1, Mon 31 Jan 2005 17:03:19 GMT, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla Summary : A utility for determining file types. Description : The file command is used to identify a file according to the type of data it contains. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats. <----------------------------------------------------------------------------------------------------------------->
Peter mentioned the possibility of your partitions being mounted noexec, what's the output of a "mount" command?
Will.
On 02/08/05, dan1 dan1@edenpics.com wrote:
So the question is: does anybody know what program is in charge of parsing that '#!/bin/sh' information, which apparently makes an error in the parsing
http://en.wikipedia.org/wiki/Shebang answers that.
The "file" package will certainly be needed for this to function correctly but I imagine your system would be really badly broken without.
# rpm -qf magic file-4.12-1.FC3.1 # rpm -qi file
Peter mentioned the possibility of your partitions being mounted noexec, what's the output of a "mount" command?
Will.
Hello, Will.
Thanks for this explanation of the magic invocation. I have tried the command you have stated above but had no results: [root@box /]# rpm -qf magic error: file magic: No such file or directory
But that is the same with the working box. However, here is the result of the second command: [root@anoigo /]# rpm -qi file Name : file Relocations: (not relocatable) Version : 4.10 Vendor: CentOS Release : 2 Build Date: Mon 21 Feb 2005 07:58:50 PM EST Install Date: Tue 02 Aug 2005 12:31:41 PM EDT Build Host: guru.build.karan. org Group : Applications/File Source RPM: file-4.10-2.src.rpm Size : 1330107 License: distributable Signature : DSA/SHA1, Sat 26 Feb 2005 03:37:03 PM EST, Key ID a53d0bab443e1821 Packager : Karanbir Singh kbsingh@centos.org Summary : A utility for determining file types. Description : The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats.
Here is also the output of the 'mount' command:
[root@box /]# mount /dev/md0 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/md1 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
Kind regards, Daniel
On 02/08/05, dan1 dan1@edenpics.com wrote:
On 02/08/05, dan1 dan1@edenpics.com wrote:
So the question is: does anybody know what program is in charge of parsing that '#!/bin/sh' information, which apparently makes an error in the parsing
http://en.wikipedia.org/wiki/Shebang answers that.
The "file" package will certainly be needed for this to function correctly but I imagine your system would be really badly broken without.
# rpm -qf magic file-4.12-1.FC3.1 # rpm -qi file
Peter mentioned the possibility of your partitions being mounted noexec, what's the output of a "mount" command?
Will.
Thanks for this explanation of the magic invocation.
No problem.
I have tried the command you have stated above but had no results: [root@box /]# rpm -qf magic error: file magic: No such file or directory
Ah, I was sat in /usr/share/file at the time. Does...
$ ls -l /usr/share/file/magic /usr/share/magic -rw-r--r-- 1 root root 356854 Apr 28 06:08 /usr/share/file/magic lrwxrwxrwx 1 root root 10 May 31 11:15 /usr/share/magic -> file/magic
Look OK on your system? If you actually less the file do its contents look OK? You should have a bunch of enties along the lines of...
#------------------------------------------------------------------------------ # commands: file(1) magic for various shells and interpreters # 0 string : shell archive or script for antique ker nel text 0 string/b #!\ /bin/sh Bourne shell script text executable 0 string/b #!\ /bin/csh C shell script text executable # korn shell magic, sent by George Wu, gwu@clyde.att.com 0 string/b #!\ /bin/ksh Korn shell script text executable
But that is the same with the working box. However, here is the result of the second command: [root@anoigo /]# rpm -qi file Name : file Relocations: (not relocatable) Version : 4.10 Vendor: CentOS Release : 2 Build Date: Mon 21 Feb 2005 07:58:50 PM EST Install Date: Tue 02 Aug 2005 12:31:41 PM EDT Build Host: guru.build.karan. org Group : Applications/File Source RPM: file-4.10-2.src.rpm Size : 1330107 License: distributable Signature : DSA/SHA1, Sat 26 Feb 2005 03:37:03 PM EST, Key ID a53d0bab443e1821 Packager : Karanbir Singh kbsingh@centos.org Summary : A utility for determining file types. Description : The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats.
That shows the file package is installed.
Here is also the output of the 'mount' command:
[root@box /]# mount /dev/md0 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/md1 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
And that confirms that nothing's mounted noexec. :o\ I can't specifically think of anything else that'd be causing this problem.
What happens if you just type in "ldd" without quotes, that's a shell script and it's in your PATH.
What about aliases and the rest of your shell environment, is there anything out of the ordinary in there? What's the output of set and env ?
Hello, Will. Inline answers are below..
Ah, I was sat in /usr/share/file at the time. Does...
$ ls -l /usr/share/file/magic /usr/share/magic -rw-r--r-- 1 root root 356854 Apr 28 06:08 /usr/share/file/magic lrwxrwxrwx 1 root root 10 May 31 11:15 /usr/share/magic -> file/magic
Look OK on your system?
Yes, exactly the same.
If you actually less the file do its contents look OK? You should have a bunch of enties along the lines of... #------------------------------------------------------------------------------ # commands: file(1) magic for various shells and interpreters # 0 string : shell archive or script for antique kernel text 0 string/b #!\ /bin/sh Bourne shell script text executable 0 string/b #!\ /bin/csh C shell script text executable # korn shell magic, sent by George Wu, gwu@clyde.att.com 0 string/b #!\ /bin/ksh Korn shell script text executable
Yes, exactly the same lines of code. At least, now I know a bit more how the shell is run when directly running the command. :-)
What happens if you just type in "ldd" without quotes, that's a shell script and it's in your PATH.
This is something interesting. If I run 'ldd', it works. Now I copied this script to the / directory and run it again with /ldd. That works too. Now I have transformed that file into my little echo script: #!/bin/sh echo testing
And that works too. So I have now two files (/ldd and /ldd2) which are scripts and which contains exactly the same content and which behaves differently, from the same directory. One is done from scratch and the other is modified from another working script.
Again each file's contents: #! /bin/sh echo testing
The result is the following when executed: [root@box /]# ./ldd testing [root@box /]# ./ldd2 [root@box /]#
Here is the file's permissions: -rwxr-xr-x 1 root root 25 Aug 2 14:07 ldd -rwxr-xr-x 1 root root 25 Aug 2 14:07 ldd2
Strange, isn't it ? Is there something else as suid bits or so which could be mixed up ?
What about aliases and the rest of your shell environment, is there anything out of the ordinary in there? What's the output of set and env ?
Here are the results: [root@box /]# set BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="00" [2]="15" [3]="1" [4]="release" [5]="i686-redhat-linux-gnu") BASH_VERSION='3.00.15(1)-release' COLORS=/etc/DIR_COLORS.xterm COLUMNS=157 DIRSTACK=() EUID=0 GROUPS=() G_BROKEN_FILENAMES=1 HISTFILE=/root/.bash_history HISTFILESIZE=1000 HISTSIZE=1000 HOME=/root HOSTNAME=box.mydomain.com HOSTTYPE=i686 IFS=$' \t\n' INPUTRC=/etc/inputrc JAVA_HOME=/usr/java/j2sdk KDEDIR=/usr LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LINES=60 LOGNAME=root LS_COLORS='no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:' MACHTYPE=i686-redhat-linux-gnu MAIL=/var/spool/mail/root MAILCHECK=60 OLDPWD=/root OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/root/bin PIPESTATUS=([0]="0") PPID=3077 PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\007"' PS1='[\u@\h \W]$ ' PS2='> ' PS4='+ ' PWD=/ QTDIR=/usr/lib/qt-3.3 SHELL=/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SSH_CLIENT='::ffff:89.214.2.219 2074 22' SSH_CONNECTION='::ffff:89.214.2.219 2074 ::ffff:151.35.1.234 22' SSH_TTY=/dev/pts/1 SUPPORTED=en_US.UTF-8:en_US:en TERM=xterm UID=0 USER=root _=./testing1
[root@anoigo /]# env HOSTNAME=box.mydomain.com TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=::ffff:89.214.2.219 2074 22 QTDIR=/usr/lib/qt-3.3 OLDPWD=/root SSH_TTY=/dev/pts/1 USER=root LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35: KDEDIR=/usr MAIL=/var/spool/mail/root PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/root/bin INPUTRC=/etc/inputrc PWD=/ JAVA_HOME=/usr/java/j2sdk LANG=en_US.UTF-8 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SHLVL=1 HOME=/root LOGNAME=root SSH_CONNECTION=::ffff:89.214.2.219 2074 ::ffff:151.35.1.234 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/bin/env
Kind regards, Daniel
Since /home/user is probably not on your path (for good security reasons), I would not expect this to run anyway.
Try moving it to /home/user/bin or a directory that is in your path.
On my CentOS4.1 system, putting it in /root does not make it work - I still have to do ./test.sh. /root is not in the path. QED.
What are the directory permissions as well? ls -ld /home/user and compare with ls -ld /root or wherever it runs OK. You only need execute access on a directory to be able to use it but you need read access if you want to find a file in it.
Have you tried strace?
strace ./test.sh 2>&1 > test.trace (or whatever)
will put a lot of stuff in test.trace. Usually it is some permission issue as you can execute it from root but not from your home directory.
Look for permission denied and other strings in the output.
Most of the obvious possibilities have already been discussed - reinstalling coreutils or binutils or whatever, filesystem mounted noexec (that's caught me out a few times - now I have a great big README in the root directory of any noexec filesystem).
HTH
John
John Logsdon "Try to make things as simple Quantex Research Ltd, Manchester UK as possible but not simpler" j.logsdon@quantex-research.com a.einstein@relativity.org +44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
On Tue, 2 Aug 2005, dan1 wrote:
Hello, Will. Inline answers are below..
Ah, I was sat in /usr/share/file at the time. Does...
$ ls -l /usr/share/file/magic /usr/share/magic -rw-r--r-- 1 root root 356854 Apr 28 06:08 /usr/share/file/magic lrwxrwxrwx 1 root root 10 May 31 11:15 /usr/share/magic -> file/magic
Look OK on your system?
Yes, exactly the same.
If you actually less the file do its contents look OK? You should have a bunch of enties along the lines of... #------------------------------------------------------------------------------ # commands: file(1) magic for various shells and interpreters # 0 string : shell archive or script for antique kernel text 0 string/b #!\ /bin/sh Bourne shell script text executable 0 string/b #!\ /bin/csh C shell script text executable # korn shell magic, sent by George Wu, gwu@clyde.att.com 0 string/b #!\ /bin/ksh Korn shell script text executable
Yes, exactly the same lines of code. At least, now I know a bit more how the shell is run when directly running the command. :-)
What happens if you just type in "ldd" without quotes, that's a shell script and it's in your PATH.
This is something interesting. If I run 'ldd', it works. Now I copied this script to the / directory and run it again with /ldd. That works too. Now I have transformed that file into my little echo script: #!/bin/sh echo testing
And that works too. So I have now two files (/ldd and /ldd2) which are scripts and which contains exactly the same content and which behaves differently, from the same directory. One is done from scratch and the other is modified from another working script.
Again each file's contents: #! /bin/sh echo testing
The result is the following when executed: [root@box /]# ./ldd testing [root@box /]# ./ldd2 [root@box /]#
Here is the file's permissions: -rwxr-xr-x 1 root root 25 Aug 2 14:07 ldd -rwxr-xr-x 1 root root 25 Aug 2 14:07 ldd2
Strange, isn't it ? Is there something else as suid bits or so which could be mixed up ?
What about aliases and the rest of your shell environment, is there anything out of the ordinary in there? What's the output of set and env ?
Here are the results: [root@box /]# set BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="00" [2]="15" [3]="1" [4]="release" [5]="i686-redhat-linux-gnu") BASH_VERSION='3.00.15(1)-release' COLORS=/etc/DIR_COLORS.xterm COLUMNS=157 DIRSTACK=() EUID=0 GROUPS=() G_BROKEN_FILENAMES=1 HISTFILE=/root/.bash_history HISTFILESIZE=1000 HISTSIZE=1000 HOME=/root HOSTNAME=box.mydomain.com HOSTTYPE=i686 IFS=$' \t\n' INPUTRC=/etc/inputrc JAVA_HOME=/usr/java/j2sdk KDEDIR=/usr LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LINES=60 LOGNAME=root LS_COLORS='no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:' MACHTYPE=i686-redhat-linux-gnu MAIL=/var/spool/mail/root MAILCHECK=60 OLDPWD=/root OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/root/bin PIPESTATUS=([0]="0") PPID=3077 PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\007"' PS1='[\u@\h \W]$ ' PS2='> ' PS4='+ ' PWD=/ QTDIR=/usr/lib/qt-3.3 SHELL=/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SSH_CLIENT='::ffff:89.214.2.219 2074 22' SSH_CONNECTION='::ffff:89.214.2.219 2074 ::ffff:151.35.1.234 22' SSH_TTY=/dev/pts/1 SUPPORTED=en_US.UTF-8:en_US:en TERM=xterm UID=0 USER=root _=./testing1
[root@anoigo /]# env HOSTNAME=box.mydomain.com TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=::ffff:89.214.2.219 2074 22 QTDIR=/usr/lib/qt-3.3 OLDPWD=/root SSH_TTY=/dev/pts/1 USER=root LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35: KDEDIR=/usr MAIL=/var/spool/mail/root PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/root/bin INPUTRC=/etc/inputrc PWD=/ JAVA_HOME=/usr/java/j2sdk LANG=en_US.UTF-8 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SHLVL=1 HOME=/root LOGNAME=root SSH_CONNECTION=::ffff:89.214.2.219 2074 ::ffff:151.35.1.234 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/bin/env
Kind regards, Daniel
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hello, John.
Since /home/user is probably not on your path (for good security reasons), I would not expect this to run anyway.
Try moving it to /home/user/bin or a directory that is in your path.
On my CentOS4.1 system, putting it in /root does not make it work - I still have to do ./test.sh. /root is not in the path. QED.
Yes, but I tested those scripts with the complete path, or with './test.sh' when being in the directory, so it doesn't seem to be related to a path problem.
What are the directory permissions as well? ls -ld /home/user and compare with ls -ld /root or wherever it runs OK. You only need execute access on a directory to be able to use it but you need read access if you want to find a file in it.
These are the permissions for those files:
[root@box /]# ls -ld /home drwxr-xr-x 6 root root 4096 Aug 2 14:58 /home [root@box /]# ls -ld /root drwxrwx--- 10 root root 4096 Aug 2 14:58 /root
/home is where the script is buggy, and /root is where the script works. Now for any reason the script works also in the / directory if I create a new one. If I copy the buggy file from /home to / it works there. If I move the buggy file from /home to / it doesn't work there... go figure..
Have you tried strace?
strace ./test.sh 2>&1 > test.trace (or whatever)
No, I haven't. I have done this right now with both the buggy and correct files. Here is the output of the difference between both strace files. It seems that there is something interesting about failing to open the /dev/tty, but I don't know how to solve that:
[root@box /]# diff /test.trace /home/test.trace 3c3 < brk(0) = 0x977b000 ---
brk(0) = 0x9cd1000
35,38c35,38 < open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3 < close(3) = 0 < brk(0) = 0x977b000 < brk(0x979c000) = 0x979c000 ---
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = -1 ENXIO (No such device or address) ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe4aa40) = -1 ENOTTY (Inappropriate ioctl for device) brk(0) = 0x9cd1000 brk(0x9cf2000) = 0x9cf2000
48c48 < time(NULL) = 1123010862 ---
time(NULL) = 1123011577
70c70 < stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 ---
stat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
72c72 < getpid() = 3144 ---
getpid() = 3168
77,78c77,78 < getppid() = 3143 < getpgrp() = 3143 ---
getppid() = 3167 getpgrp() = 3167
82c82 < ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff0f1c8) = -1 ENOTTY (Inappropriate ioctl for device) ---
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe4ab58) = -1 ENOTTY (Inappropriate ioctl for device)
96c96,97 < fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 ---
fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe4a28c) = -1 ENOTTY (Inappropriate ioctl for device)
It seems that we are getting nearer this time ..
Thanks, Daniel
On 02/08/05, dan1 dan1@edenpics.com wrote:
This is something interesting. If I run 'ldd', it works. Now I copied this script to the / directory and run it again with /ldd. That works too. Now I have transformed that file into my little echo script: #!/bin/sh echo testing
And that works too. So I have now two files (/ldd and /ldd2) which are scripts and which contains exactly the same content and which behaves differently, from the same directory. One is done from scratch and the other is modified from another working script.
Again each file's contents: #! /bin/sh echo testing
The result is the following when executed: [root@box /]# ./ldd testing [root@box /]# ./ldd2 [root@box /]#
That is unusual. What are you using to edit these files? I seem to recall one of my users having some weirdness with shell scripts because the lines weren't terminated properly.
Compare the output from...
$ cat -A /ldd $ cat -A /ldd2
As JohnL pointed out, strace might be helpful too.
Will.
This is something interesting. If I run 'ldd', it works. Now I copied this script to the / directory and run it again with /ldd. That works too. Now I have transformed that file into my little echo script: #!/bin/sh echo testing
And that works too. So I have now two files (/ldd and /ldd2) which are scripts and which contains exactly the same content and which behaves differently, from the same directory. One is done from scratch and the other is modified from another working script.
Again each file's contents: #! /bin/sh echo testing
The result is the following when executed: [root@box /]# ./ldd testing [root@box /]# ./ldd2 [root@box /]#
That is unusual. What are you using to edit these files? I seem to recall one of my users having some weirdness with shell scripts because the lines weren't terminated properly.
Compare the output from...
$ cat -A /ldd $ cat -A /ldd2
Hello again, Will.
Good idea. Here is what those files are containing exactly: [root@box /]# cat -A /ldd #! /bin/sh$ echo testing$ $ [root@box /]# cat -A /ldd2 #! /bin/sh$ echo testing$ $ [root@box /]#
They seem exactly the same.. BTW now, for any reason, I can create a new file in the / directory and run it properly (before it always didn't output anything). However by creating that in the /home directory it won't work, like before in /.
Regards, Daniel
On 02/08/05, dan1 dan1@edenpics.com wrote:
Again each file's contents: #! /bin/sh echo testing
The result is the following when executed: [root@box /]# ./ldd testing [root@box /]# ./ldd2 [root@box /]#
That is unusual. What are you using to edit these files? I seem to recall one of my users having some weirdness with shell scripts because the lines weren't terminated properly.
Compare the output from...
$ cat -A /ldd $ cat -A /ldd2
Hello again, Will.
Good idea. Here is what those files are containing exactly: [root@box /]# cat -A /ldd #! /bin/sh$ echo testing$ $ [root@box /]# cat -A /ldd2 #! /bin/sh$ echo testing$ $ [root@box /]#
OK, those both look identical, but ldd2 doesn't run?
They seem exactly the same.. BTW now, for any reason, I can create a new file in the / directory and run it properly (before it always didn't output anything). However by creating that in the /home directory it won't work, like before in /.
This is weird, could it be SELinux related? Have you got SELinux enabled? And if so, can it be switched off to check if it's the cause of the problem?
Will.
This is weird, could it be SELinux related? Have you got SELinux enabled? And if so, can it be switched off to check if it's the cause of the problem?
Will.
Will, you found out the problem !!! Big thanks ! The problem was seated in the SElinux which was enforcing. Disabling it solved the problem. Now as I would still prefer to keep SElinux, I don't know exactly what I should do to make that work with it enabled.
Here is the list of the SElinux properties (the context) for these files:
Correct file in /, ls -alZ: -rwxr-xr-x root root root:object_r:root_t test.sh
Buggy file in /home, ls -alZ: -rwxr-xr-x root root root:object_r:httpd_sys_content_t test.sh
I have changed that context for all the /home directory to httpd_sys_content_t for apache to be able to display those files, this is the reason of the difference. However, I have installed JAVA tomcat and it has also automatically set /usr/java/jakarta-tomcat/bin/startup.sh in the same context without me asking that. This is also the reason why this script doesn't work there. However, why did this file set itself in this context, any idea ? BTW this was not the case on my other box where I also have JAVA installed and the statup.sh script works perfectly.
Also what context should I put my files to, if I want to make sure that I can execute them and also be able to see them with apache (a link on one users's subdirectory) ? In the worst case I can still disable SElinux, but I'd rather keep it for security reasons.
Thanks a lot, Daniel
What about force re-installing (replacing) bash & coreutils rpms?? Also, Try switching to runlevel 1 & re-run the script, if it works try replacing bash_profile, /etc/bashrc and (or) ~/.bashrc from the good system
I hope this will help
----- Original Message ----- From: "dan1" dan1@edenpics.com To: "CentOS mailing list" centos@centos.org Sent: Tuesday, August 02, 2005 11:48 AM Subject: Re: [CentOS] bash file direct execution
Hello all.
To continue with the problem I am facing, I have some news..
When I delete the line #!/bin/sh then the script works perfectly. When I put it again then the problem occurs again. So the script just containing 'echo test' just works fine, but the script: #!/bin/sh echo test
doesn't work (except when put in the /root directory) ... and this is true for all other scripts.
So the question is: does anybody know what program is in charge of parsing that '#!/bin/sh' information, which apparently makes an error in the parsing ? Is there any linux guru that would know of it ?
Thanks, Daniel
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
What about force re-installing (replacing) bash & coreutils rpms?? Also, Try switching to runlevel 1 & re-run the script, if it works try replacing bash_profile, /etc/bashrc and (or) ~/.bashrc from the good system
I hope this will help
Hello, Egypt.com. Thanks for the suggestions. I have tried them all but that did not solve the problem. I reinstalled the packages bash, coreutils, and file. I also replaced those 3 files above from the working station to the buggy station without any effect, even after reboot.
Still thanks for that, Daniel
} Hello all. } To continue with the problem I am facing, I have some news.. } When I delete the line #!/bin/sh then the script works perfectly. When I } put it again then the problem occurs again. } So the script just containing 'echo test' just works fine, but the script: } #!/bin/sh } echo test } doesn't work (except when put in the /root directory) ... and this is true } for all other scripts. } So the question is: does anybody know what program is in charge of parsing } that '#!/bin/sh' information, which apparently makes an error in the } parsing ? } Is there any linux guru that would know of it ? } Daniel
greetings,
may i ask what text editor you use? vi? pico? other?
- rh
-- Robert Hanson Abba Communications http://www.abbacomm.net
} Hello all. } To continue with the problem I am facing, I have some news.. } When I delete the line #!/bin/sh then the script works perfectly. When I } put it again then the problem occurs again. } So the script just containing 'echo test' just works fine, but the script: } #!/bin/sh } echo test } doesn't work (except when put in the /root directory) ... and this is true } for all other scripts. } So the question is: does anybody know what program is in charge of parsing } that '#!/bin/sh' information, which apparently makes an error in the } parsing ? } Is there any linux guru that would know of it ? } Daniel
greetings,
may i ask what text editor you use? vi? pico? other?
- rh
-- Robert Hanson
Hello, Robert. Yes, I use vi.
But the solution has just been found: it was SElinux that was not setup properly. You can have a look at the last thread with [half-solved]
Thanks anyway! Daniel
-
BRUCE STANLEY -
dan1 -
Egypt.com -
John Logsdon -
Johnny Hughes -
Matt Hyclak -
Peter Arremann -
Robert Hanson -
Will McDonald