Hi there,i'm sorry about all my stupid question,but..so the point is
this whit awk i can read from file to the directory and sed i can
write,so ,inside a directory /opt/DTT i've many scripts almost 50,that
starts with #/usr/bin/sh or /usr/bin/ksh and many others that relies
on subdirectory.How can i change those files from #/usr/bin/sh #/usr/
bin/ksh in #/bin/sh #/bin/ksh on ane line?
Thank you in advanced
On 28 Gen, 06:14, franzi
> Hi there,i'm sorry about all my stupid question,but..so the point is
> this whit awk i can read from file to the directory and sed i can
> write,so ,inside a directory /opt/DTT i've many scripts almost 50,that
> starts with #/usr/bin/sh or /usr/bin/ksh and many others that relies
> on subdirectory.How can i change those files from #/usr/bin/sh #/usr/
> bin/ksh in #/bin/sh #/bin/ksh on ane line?
> Thank you in advanced
AH let me tell one more thing,inside that directory /opt/DTT there are
some files ending in .d those are ok,the othere one not
On Sun, 27 Jan 2008 21:17:47 -0800 (PST), franzi wrote:
> On 28 Gen, 06:14, franzi
>> Hi there,i'm sorry about all my stupid question,but..so the point is
>> this whit awk i can read from file to the directory and sed i can
>> write,so ,inside a directory /opt/DTT i've many scripts almost 50,that
>> starts with #/usr/bin/sh or /usr/bin/ksh and many others that relies
>> on subdirectory.How can i change those files from #/usr/bin/sh #/usr/
>> bin/ksh in #/bin/sh #/bin/ksh on ane line?
>> Thank you in advanced
>
> AH let me tell one more thing,inside that directory /opt/DTT there are
> some files ending in .d those are ok,the othere one not
Should be #!/bin/sh or #! /bin/sh for better legibility.
find /opt/DTT ! -name '*.d' -exec perl -pi.back '
s{^#!?\s*/usr/bin/(k?sh)}{#! /bin/$1} if ($. == 1)' {} \;
(not tested).
--
Stephane
Stephane Chazelas
> Should be #!/bin/sh or #! /bin/sh for better legibility.
On some systems, I have seen #!sh . This worked incredibly well,
allowing the system to follow the PATH environment to locate the appropriate
interpreter. (This is contrary to the Single Unix Specification.)
I actually preferred this system, but unfortunately it does not work on
Linux, which returns an error:
Bad Interpreter: sh
With regards to the space following the hashbang, some systems will not
work with the space there, and rumour has it that some 64 bit systems
require the space, although I read a report from someone who tested
this, and it was stated that the hashbang line worked fine without the
space on all of the systems he tried.
I suggest, don't put the space unless you have to. If you want the
script to be portable across systems, use a full pathname following the
hashbang. If your system allows it, and you are not bothered about SUS
compliance, or portability then strip the pathname, allowing the system to
locate the shell via its PATH mechanisms.
Regards,
Mark.
--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.
On Mon, 28 Jan 2008 10:08:04 GMT, Mark Hobley wrote:
> Stephane Chazelas
>> Should be #!/bin/sh or #! /bin/sh for better legibility.
>
> On some systems, I have seen #!sh . This worked incredibly well,
> allowing the system to follow the PATH environment to locate the appropriate
> interpreter. (This is contrary to the Single Unix Specification.)
?! What system was that? Never heard of it.
[...]
> With regards to the space following the hashbang, some systems will not
> work with the space there, and rumour has it
Never heard either and I'm sure Sven will also be interested in
which system has that limitation.
Could you please give system names and versions?
See http://www.in-ulm.de/~mascheck/various/shebang/ for Sven's
page on the shebang.
As far as I know, relative path is not allowed (at least not by
the system) and spaces after #! are always allowed though never
required, but please prove me wrong if you have reliable
information that proves the contrary.
--
Stephane
Stephane Chazelas
> ?! What system was that? Never heard of it.
I'm not sure. It was in the field, maybe system V, HPUX or Sco Open
Server. I have definately seen it.
I'll dig through some of my old manuals, to see if I can find anything.
Maybe there is a way to query the expression on Google also, but its
coming up with too much crap for me.
>> With regards to the space following the hashbang, some systems will
not
>> work with the space there, and rumour has it
Mike Tremell writes in his article "The Shebang Line", when refering to
the space between the hashbang and the interpreter name:
Lots of shells nowadays will consume this blank space for you. Some
older versions of shells are far less forgiving.
> See http://www.in-ulm.de/~mascheck/various/shebang/ for Sven's
> page on the shebang.
Yeah, I had seen that page before. I was just looking again at that to
see if the #!sh had been spotted, but there is no mention of it.
> As far as I know, relative path is not allowed (at least not by
> the system)
Yeah, I wasn't expecting a relative path, but I was hoping that just the
shell name would work, using the PATH environmental.
Interestingly both "Unix Shell Programming" by BPB and "Unix Shell
Programming" by Hayden Books, have no mention of a hashbang, and the
Hayden book, actually mentions executing the script from the command
line following a chmod u+x. These are both based on System V.
Regards,
Mark.
--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.
markhobley@hotpop.donottypethisbit.com (Mark Hobley) writes:
>Mike Tremell writes in his article "The Shebang Line", when refering to
>the space between the hashbang and the interpreter name:
Which is a strange comment because the #! line is generally NOT
interpreted by a shell at all (and research seems to suggest the space
was never always ignored)
>Interestingly both "Unix Shell Programming" by BPB and "Unix Shell
>Programming" by Hayden Books, have no mention of a hashbang, and the
>Hayden book, actually mentions executing the script from the command
>line following a chmod u+x. These are both based on System V.
And in those cases it is the shell which, upon failing to execute
a file, will attempt to execute it as a script.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
On Mon, 28 Jan 2008 12:08:03 GMT, Mark Hobley wrote:
[...]
>> As far as I know, relative path is not allowed (at least not by
>> the system)
>
> Yeah, I wasn't expecting a relative path, but I was hoping that just the
> shell name would work, using the PATH environmental.
[...]
Also, the environment is pretty much a user-space concept. As
far as the kernel is concerned, it's just a list of strings
passed along the execve system call. So I very much doubt that a
kernel would go as far as parsing the environment of a process
(especially when you consider that in many implementations, the
libc has relocated it so the kernel wouldn't know where to find
it) for a variable called PATH to find the path of an
interpreter.
So, that would have had to be before the times where the kernel
was parsing the shebang line. So, we should be able to narrow
the search to the shells available at that time (csh, Bourne
and ksh I suppose).
Upon execve'ing #! sh, modern systems would return ENOENT, not
ENOEXEC, so the calling shell wouldn't attempt to parse the line
itself.
And if ENOEXEC was returned, I think most shells would have the
script interpreted by sh or csh or a fork of themselves, not by
the interpreter resolved from "sh".
So,
#! sh
may work on some old systems, but not for the reason you think,
only because the shell will call sh regardless of the content of
that line..
> Mike Tremell writes in his article "The Shebang Line", when refering to
> the space between the hashbang and the interpreter name:
>
> Lots of shells nowadays will consume this blank space for you. Some
> older versions of shells are far less forgiving.
[...]
That text must have been written a long time ago (I mean decades
ago). Nowadays, it's not the shell that parses that line (I'm
not even sure any historical shell ever did parse the #! line,
Sven may want to add more on this), it's the OS. It seems more
like the author doesn't know what he is talking about.
In modern shells, zsh is the only shell that I know of that may
parse that line under some circumstances. But it only happens when
the system returns ENOEXEC (like for instance, when trying to
use #! /interpreter where /interpreter is itself a script)
$ cat a
#! /bin/echo
$ cat b
#! /home/stephane/a
$ strace -fe execve zsh -c ./b
execve("/usr/bin/zsh", ["zsh", "-c", "./b"], [/* 40 vars */]) = 0
execve("./b", ["./b"], [/* 40 vars */]) = -1 ENOEXEC (Exec format error)
execve("/home/stephane/a", ["/home/stephane/a", "./b"], [/* 40 vars */]) = 0
/home/stephane/a ./b
(and note that zsh parses it in its own way which may be
different from the kernel's).
All of the other shells (at least csh, tcsh, rc, bash, ash, ksh,
pdksh, mksh...) give up in that case upon the first execve, and
either report a "bad exec format" or have the script interpreted
by sh or a fork of themselves.
--
Stephane
Stephane Chazelas
>Also, the environment is pretty much a user-space concept. As
>far as the kernel is concerned, it's just a list of strings
>passed along the execve system call. So I very much doubt that a
>kernel would go as far as parsing the environment of a process
>(especially when you consider that in many implementations, the
>libc has relocated it so the kernel wouldn't know where to find
>it) for a variable called PATH to find the path of an
>interpreter.
The kernel is perfectly capable of locating the environment
at exactly one moment only: at exec() time when it needs the
strings to copy them into the new process images which is being
created. And that happens to be precisely the point we are
So it is possible; it's just not done in any implementation
we have discussed this far.
>So, that would have had to be before the times where the kernel
>was parsing the shebang line. So, we should be able to narrow
>the search to the shells available at that time (csh, Bourne
>and ksh I suppose).
>Upon execve'ing #! sh, modern systems would return ENOENT, not
>ENOEXEC, so the calling shell wouldn't attempt to parse the line
>itself.
Yep; though it's fun to see that "#!sh works just fine after
you've cd'ed to /bin or /usr/bin
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
On 28 Jan 2008 16:15:04 GMT, Casper H.S Dik wrote:
> Stephane Chazelas
>
>>Also, the environment is pretty much a user-space concept. As
>>far as the kernel is concerned, it's just a list of strings
>>passed along the execve system call. So I very much doubt that a
>>kernel would go as far as parsing the environment of a process
>>(especially when you consider that in many implementations, the
>>libc has relocated it so the kernel wouldn't know where to find
>>it) for a variable called PATH to find the path of an
>>interpreter.
>
> The kernel is perfectly capable of locating the environment
> at exactly one moment only: at exec() time when it needs the
> strings to copy them into the new process images which is being
> created. And that happens to be precisely the point we are
> So it is possible; it's just not done in any implementation
> we have discussed this far.
Oops, of course, indeed you're right, how embarassing...
>>So, that would have had to be before the times where the kernel
>>was parsing the shebang line. So, we should be able to narrow
>>the search to the shells available at that time (csh, Bourne
>>and ksh I suppose).
>
>>Upon execve'ing #! sh, modern systems would return ENOENT, not
>>ENOEXEC, so the calling shell wouldn't attempt to parse the line
>>itself.
>
> Yep; though it's fun to see that "#!sh works just fine after
> you've cd'ed to /bin or /usr/bin
[...]
My bad again, I had said in a previous post that relative
paths were not supported. You're confirming that they are. I
could verify it on Linux, HPUX and Solaris. And that explains
the ENOENT.
Thanks for the corrections.
--
Stephane
Mark Hobley wrote:
> Mike Tremell writes in his article "The Shebang Line"
Fascinating, many mistakes seem to be coacting together.
Just one example from it [1],
| #!/bin/rm
|
| the default action of the shell would be to delete the file and then run
| all the following commands (reading the script - in both shell and Perl
| - left to right, from top to bottom) until the script ended. If this
| seems counterintuitive, which it did to me at one point, that's normal."
Did he try that at all before publishing?
[1]
http://linuxshellaccount.blogspot.com/2007/12/shebang-line-i ntroduction-to-porting.html
Stephane Chazelas wrote:
> [...] I'm not even sure any historical shell ever did parse the #! line,
I don't believe either, but apart from zsh there are more modern examples:
bash-1 always took over upon ENOEXEC, see execute_cmd.c,
"If the operating system on which we're running does not handle
the #! executable format, then help out. [...]"
In bash-2/3 this is only activated if the #! mechanism is
unavailable at compile time (e.g. older cygwins?).
In article <479dff88$0$85780$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik
> Stephane Chazelas
>
> >Also, the environment is pretty much a user-space concept. As
> >far as the kernel is concerned, it's just a list of strings
> >passed along the execve system call. So I very much doubt that a
> >kernel would go as far as parsing the environment of a process
> >(especially when you consider that in many implementations, the
> >libc has relocated it so the kernel wouldn't know where to find
> >it) for a variable called PATH to find the path of an
> >interpreter.
>
> The kernel is perfectly capable of locating the environment
> at exactly one moment only: at exec() time when it needs the
> strings to copy them into the new process images which is being
> created. And that happens to be precisely the point we are
> So it is possible; it's just not done in any implementation
> we have discussed this far.
What about the exec{l,v}p() system calls? Don't they search the PATH?
Or is it actually done by the libc wrapper, which does the searching in
user space and then calls exec{l,v}e()?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Mon, 28 Jan 2008 21:11:37 -0500, Barry Margolin wrote:
> In article <479dff88$0$85780$e4fe514c@news.xs4all.nl>,
> Casper H.S. Dik
>
>> Stephane Chazelas
>>
>> >Also, the environment is pretty much a user-space concept. As
>> >far as the kernel is concerned, it's just a list of strings
>> >passed along the execve system call. So I very much doubt that a
>> >kernel would go as far as parsing the environment of a process
>> >(especially when you consider that in many implementations, the
>> >libc has relocated it so the kernel wouldn't know where to find
>> >it) for a variable called PATH to find the path of an
>> >interpreter.
>>
>> The kernel is perfectly capable of locating the environment
>> at exactly one moment only: at exec() time when it needs the
>> strings to copy them into the new process images which is being
>> created. And that happens to be precisely the point we are
>> So it is possible; it's just not done in any implementation
>> we have discussed this far.
>
> What about the exec{l,v}p() system calls? Don't they search the PATH?
> Or is it actually done by the libc wrapper, which does the searching in
> user space and then calls exec{l,v}e()?
[...]
I always assumed it was done by the libc as $PATH is a
user-space concept. Seems to be the case at least on Solaris,
HPUX and the GNU libc on Linux.
--
Stephane
In article <479dd391$0$890$ba4acef3@news.orange.fr>,
Stephane Chazelas
>So, that would have had to be before the times where the kernel
>was parsing the shebang line. So, we should be able to narrow
>the search to the shells available at that time (csh, Bourne
>and ksh I suppose).
>
>Upon execve'ing #! sh, modern systems would return ENOENT, not
>ENOEXEC, so the calling shell wouldn't attempt to parse the line
>itself.
>
>And if ENOEXEC was returned, I think most shells would have the
>script interpreted by sh or csh or a fork of themselves, not by
>the interpreter resolved from "sh".
>
>So,
>
>#! sh
>
>may work on some old systems, but not for the reason you think,
>only because the shell will call sh regardless of the content of
>that line..
>
>> Mike Tremell writes in his article "The Shebang Line", when refering to
>> the space between the hashbang and the interpreter name:
>>
>> Lots of shells nowadays will consume this blank space for you. Some
>> older versions of shells are far less forgiving.
>[...]
>
>That text must have been written a long time ago (I mean decades
>ago). Nowadays, it's not the shell that parses that line (I'm
>not even sure any historical shell ever did parse the #! line,
ksh88 did this, for the sake of OSes that didn't support #! (like XENIX).
John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
On Tue, 29 Jan 2008 23:28:01 -0000, John DuBois wrote:
> In article <479dd391$0$890$ba4acef3@news.orange.fr>,
> Stephane Chazelas
>>So, that would have had to be before the times where the kernel
>>was parsing the shebang line. So, we should be able to narrow
>>the search to the shells available at that time (csh, Bourne
>>and ksh I suppose).
>>
>>Upon execve'ing #! sh, modern systems would return ENOENT, not
>>ENOEXEC, so the calling shell wouldn't attempt to parse the line
>>itself.
>>
>>And if ENOEXEC was returned, I think most shells would have the
>>script interpreted by sh or csh or a fork of themselves, not by
>>the interpreter resolved from "sh".
>>
>>So,
>>
>>#! sh
>>
>>may work on some old systems, but not for the reason you think,
>>only because the shell will call sh regardless of the content of
>>that line..
>>
>>> Mike Tremell writes in his article "The Shebang Line", when refering to
>>> the space between the hashbang and the interpreter name:
>>>
>>> Lots of shells nowadays will consume this blank space for you. Some
>>> older versions of shells are far less forgiving.
>>[...]
>>
>>That text must have been written a long time ago (I mean decades
>>ago). Nowadays, it's not the shell that parses that line (I'm
>>not even sure any historical shell ever did parse the #! line,
>
> ksh88 did this, for the sake of OSes that didn't support #! (like XENIX).
[...]
Hi John, when you say "this", do you mean "parse the #! line"?
Are you sure it was not something added by XENIX. The ksh88 on
Solaris 7 doesn't do it:
$ cat > a
#! /bin/echo echo:
$ cat > b
#! /home/stephane/a
$ chmod +x a b
$ ksh -c ./b
$ zsh -c ./b
echo: /home/stephane/a ./b
Above, the system returns ENOEXEC upon execve() of b. ksh does
interpret the script in a fork of itself (which POSIX doesn't
require as the first line starts with #!) in that case, it
doesn't parse the shebang line. zsh does.
Or maybe it's something enabled at compile time like for bash 2
and above?
From a quick reading of the ksh93 code, there doesn't seem to be
any code that parses the shebang line, nor anything in the
"RELEASE" files that indicated that such code has been removed
since ksh88, hence my questionning.
--
Stephane
In article <47a0366e$0$882$ba4acef3@news.orange.fr>,
Stephane Chazelas
>> ksh88 did this, for the sake of OSes that didn't support #! (like XENIX).
>[...]
>
>Hi John, when you say "this", do you mean "parse the #! line"?
>
>Are you sure it was not something added by XENIX. The ksh88 on
>Solaris 7 doesn't do it:
>
>$ cat > a
>#! /bin/echo echo:
>$ cat > b
>#! /home/stephane/a
>$ chmod +x a b
>$ ksh -c ./b
>$ zsh -c ./b
>echo: /home/stephane/a ./b
>
>Above, the system returns ENOEXEC upon execve() of b. ksh does
>interpret the script in a fork of itself (which POSIX doesn't
>require as the first line starts with #!) in that case, it
>doesn't parse the shebang line. zsh does.
>
>Or maybe it's something enabled at compile time like for bash 2
>and above?
>
>From a quick reading of the ksh93 code, there doesn't seem to be
>any code that parses the shebang line, nor anything in the
>"RELEASE" files that indicated that such code has been removed
>since ksh88, hence my questionning.
I was wrong - it was indeed part of the ksh88 distribution, but it turns out
that it was a side effect of code for a vfork optimization, not for the sake of
systems that didn't support #!.
From the ksh88 README:
VFORK Set on systems where vfork() is much faster than fork().
This has not been fully debugged in this release.
vfork.c included this function:
/*
* Get the interpreter name given a script file
* The first line must be of the form #!
* Returns 1 if
*/
int get_shell(name,iname)
and was called from #ifdef VFORK code in execs():
case ENOEXEC:
....
if(get_shell(p, iname)<0)
sh_fail(p, e_exec);
t--;
t[0] = iname;
execve(iname, t, xecenv);
This appears to all be gone in ksh93. I built ksh88g with -DVFORK and ran your
test (much nicer than what I had thought of to test this on a system that does
support #!), and it produced the same result as zsh.
John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/