first of all, i would like to wish all gnu/linuxers a very happy and a prosperous new year!
now coming to my problem:- i recently installed RedHat 9 on my m/c. i also have RedHat 7.3 on a separate partition. when i logged into RedHat 9, even the simplest shell scripts, like ------------------------------------------------------------------------------------------------ #tmp.sh #!/bin/bash echo "sdjfljsd" ------------------------------------------------------------------------------------------------ don't work after i do: - $ chmod +x tmp.sh $ ./tmp.sh but this works:- $ bash tmp.sh
the first case gives the foll error:- bash: bad interpreter .....
when i log into RedHat 7.3, and try to do a "chroot" to the "/" of the RedHat 9 partition, i get the error:- bash: Permission denied
i even tried copying /bin/bash from RedHat 7.3 to RedHat 9, but it did not help. any help regarding this problem would be greatly appreciated.
thanks for the help!
-- You can teach a student a lesson for a day; but if you can teach him to learn by creating curiosity, he will continue the learning process as long as he lives. - Clay Bedford.
--- Pradnyesh Sawant spradnyesh@gmx.net Ph. 91-022-27703060 http://www.geocities.com/spradnyesh ---
On Thu, Jan 01, 2004 at 10:16:06AM +0530, psawant@nse.co.in wrote:
#tmp.sh #!/bin/bash echo "sdjfljsd"
From the bash man-page:
If the program is a file beginning with #!, the remainder of the first line specifies an interpreter for the program. The shell executes the specified interpreter on operating systems that do not handle this executable format themselves. The arguments to the interpreter consist of a single optional argu- ment following the interpreter name on the first line of the program, followed by the name of the pro- gram, followed by the command arguments, if any.
This basically means that the start of your script is incorrect. Remove the first line. The first line should always be a "#!/bin/bash"
when i log into RedHat 7.3, and try to do a "chroot" to the "/" of the RedHat 9 partition, i get the error:- bash: Permission denied
Are you logged in as root when you try to chroot?
i even tried copying /bin/bash from RedHat 7.3 to RedHat 9, but it did not help.
Bad idea in all cases. Read the docs, don't play with system files!
Sameer.
Sameer D. Sahasrabuddhe wrote:
This basically means that the start of your script is incorrect. Remove the first line. The first line should always be a "#!/bin/bash"
below is a script ... which has many lines as comments at the start. still it works.
#test.sh #it doesn;t matter how # many lines u write # as comments before start of the script. #!/bin/bash #!/bin/csh echo "HAPPY NEW YR"
this works but wonder in such case. ... which shell ll be invoked .... bash or csh?
On Fri, Jan 02, 2004 at 10:20:56AM +0530, Amey Gokhale wrote:
This basically means that the start of your script is incorrect. Remove the first line. The first line should always be a "#!/bin/bash"
below is a script ... which has many lines as comments at the start. still it works.
I did some experiments with a test script, and here's what I found. I think this behaviour depends a lot on the way each distribution of GNU/Linux handles shell scripts. I use a Debian box, and /bin/bash seems to be the _default handler_ for shell scripts, which is used /if the script does not specify a handler/. How do we test this?
From the bash manpage
Shell Variables BASH Expands to the full file name used to invoke this instance of bash.
So I wrote a script with single line in it:
echo $BASH
Since I didn't specify a handler, the result was "/bin/bash"
Change that to:
#!/bin/csh echo $BASH
This time the result was "BASH: Undefined variable." This happened because I do have the real csh installed on my system, which was invoked correctly.
Now by Debian policy, /bin/csh is a symlink to the real csh somewhere else. I changed that so that /bin/csh points to /bin/bash. This time the result was "/bin/csh". This was because now the script was processed by bash masquerading as csh.
Moral of the story? Don't conclude non-existing features by looking at default behaviours ... read the manpages instead!
Sameer.