15 Jul
2016
15 Jul
'16
4:47 p.m.
Gerard Holzmann took the true and false commands as
the jumping-off point for "Code Inflation", an
installment of his "Reliable Code" blog and column
in IEE Software. An informative, but depressing, read:
http://spinroot.com/gerard/pdf/Code_Inflation.pdf
Doug
10 Sep
10 Sep
5:40 p.m.
New subject: Shell control through external commands
Il 15/07/2016 alle 18:47, Doug McIlroy ha scritto:
Gerard Holzmann took the true and false commands as
the jumping-off point for "Code Inflation", an
installment of his "Reliable Code" blog and column
in IEE Software. An informative, but depressing, read:
http://spinroot.com/gerard/pdf/Code_Inflation.pdf
I just reclaimed 56K of disk space by replacing the GNU versions of
/bin/true and /bin/false with hand-made reproductions of the earliest
versions.
I never knew that a shell script could work without a shebang line.
7:22 p.m.
New subject: Shell control through external commands
Dario Niedermann <dnied(a)tiscali.it> wrote:
I never knew that a shell script could work without a
shebang line.
That was the simplicity of the original system, where you just made the
file executable. The shell would fork and exec as usual. When the exec
failed, the shell noticed that errno was ENOEXEC (not a runnable file)
and started interpreting the script itself.
This broke down as soon as there were two shells (/bin/sh and csh) since
if you tried to run a csh script from the Bourne shell or vice versa,
things weirded out pretty quickly.
IIRC #! originated at Bell Labs but it got out to the world via BSD.
Perhaps Dr. McIlroy could confirm / deny / expand upon the details (please?)
Thanks,
Arnold
12 Sep
12 Sep
8:35 a.m.
New subject: Shell control through external commands
[2016-09-10 13:22] arnold(a)skeeve.com
Dario Niedermann <dnied(a)tiscali.it> wrote:
I think I've seen many eary (pre-Shebang and even pre-#-comment)
shell scripts start with a colon. Is this only a coincidence with
having a comment at the beginning or was the colon character magic
in some way?
meillo
I never knew that a shell script could work without a shebang line.
That was the simplicity of the original system, where you just made the
file executable. The shell would fork and exec as usual. When the exec
failed, the shell noticed that errno was ENOEXEC (not a runnable file)
and started interpreting the script itself. 
9:25 a.m.
New subject: Shell control through external commands
markus schnalke <meillo(a)marmaro.de> wrote:
I think I've seen many eary (pre-Shebang and even
pre-#-comment)
shell scripts start with a colon. Is this only a coincidence with
having a comment at the beginning or was the colon character magic
in some way?
The colon was introduced by AT&T around 1983. It was used for Bourne Shell
scripts. Some of these scripts made it into SVr4 and caused problems with
non-Bourne compatible other shells.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'
12:41 p.m.
New subject: Shell control through external commands
Joerg Schilling <schily(a)schily.net> wrote:
The colon was introduced by AT&T around 1983.
It's a builtin in the v7 Bourne shell - see SYSNULL in msg.c (which
has the command name table) and in xec.c (which has the implementation)
http://www.tuhs.org/Archive/PDP-11/Trees/V7/usr/src/cmd/sh/
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode
Southeast Fitzroy: Southerly becoming cyclonic, 5 to 7, occasionally 4 later.
Moderate or rough, occasionally very rough at first. Rain or showers. Good,
occasionally poor.
12:50 p.m.
New subject: Shell control through external commands
Tony Finch <dot(a)dotat.at> wrote:
Joerg Schilling <schily(a)schily.net> wrote:
You are missinterpeting things.
The colon in line one as a hint to a modified csh to call the Bourne Shell
first appeared around 1983.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'
The colon was introduced by AT&T around 1983.
It's a builtin in the v7 Bourne shell - see SYSNULL in msg.c (which
has the command name table) and in xec.c (which has the implementation) 
13 Sep
13 Sep
12:17 a.m.
New subject: Shell control through external commands
On Mon, Sep 12, 2016 at 02:50:10PM +0200, Joerg Schilling wrote:
You are missinterpeting things.
The colon in line one as a hint to a modified csh to call the Bourne Shell
first appeared around 1983.
I'm still confused (you're short with context): what does "introduced by
AT&T" mean?
I only know the #-hacked csh from 2BSD+ ('79), and the #-hacked sh from 3BSD+
('80).
How would ":" as a hint in this respect show up on other systems?
BTW: academic but funny side effect of : as no-op instead of real comment:
: `echo output 1>&2`
actually writes to stderr.
Normal Wilson wrote:
The colon was introduced by AT&T around 1983.
It's a builtin in the v7 Bourne shell - see SYSNULL in msg.c (which
has the command name table) and in xec.c (which has the implementation) [...] A hack emerged: if csh encountered a script
file, it would read the
first character; if that was '#' it was a csh script, otherwise it handed
off to /bin/sh.
lesser known fact: even sh was hacked on BSDs (since 3BSD) with this #-csh magic,
and also exec'ed to csh. This then co-existed with the soon coming implementation
of "#" as comment character.
-Sven
1:45 a.m.
New subject: Shell control through external commands
Sven Mascheck wrote:
Ok, so they included csh with SysV, but SVR1 had no #! yet.
Less confused but still curious: what problems did show up with : then?
-Sven
Joerg Schilling wrote:
> > The
colon was introduced by AT&T around 1983.
[...]
I'm still confused (you're short with context): what does "introduced by
AT&T" mean?
9:20 a.m.
New subject: Shell control through external commands
Sven Mascheck <mascheck(a)in-ulm.de> wrote:
On Mon, Sep 12, 2016 at 02:50:10PM +0200, Joerg
Schilling wrote:
You are missinterpeting things.
The colon in line one as a hint to a modified csh to call the Bourne Shell
first appeared around 1983.
I'm still confused (you're short with context): what does "introduced by
AT&T" mean?
I only know the #-hacked csh from 2BSD+ ('79), and the #-hacked sh from 3BSD+
('80).
How would ":" as a hint in this respect show up on other systems?
This is long ago, so my memory is not good anymore.
Aprox. 30 years ago, I ported my shell to a svr3 system and discovered problems.
AFAIR, this system had special treatment for scripts starting with ":".
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
The colon was introduced by AT&T around 1983.
It's a builtin in the v7 Bourne shell - see SYSNULL in msg.c (which
has the command name table) and in xec.c (which has the implementation) 
12 Sep
12 Sep
8:12 p.m.
New subject: Shell control through external commands
On Mon, 12 Sep 2016, markus schnalke wrote:
I think I've seen many eary (pre-Shebang and even
pre-#-comment) shell
scripts start with a colon. Is this only a coincidence with having a
comment at the beginning or was the colon character magic in some way?
Minor nit: ":" is not precisely a comment, but an empty label. Ano no,
it's not particularly magic in any way, as I recall.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
9:36 p.m.
New subject: Shell control through external commands
On Tue, 13 Sep 2016, Dave Horsfall wrote:
Minor nit: ":" is not precisely a comment,
but an empty label. Ano no,
it's not particularly magic in any way, as I recall.
Oops - I didn't know that CSH treated it specially... I'm not a CSH
programmer, never have been, and never will be (it ought to attract the
death penalty).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
10 Sep
10 Sep
10:43 p.m.
New subject: Shell control through external commands
On Sat, 10 Sep 2016, Dario Niedermann wrote:
I never knew that a shell script could work without a
shebang line.
I believe it was used to specify an interpreter other than /bin/sh (the
default).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
11 Sep
11 Sep
1:24 a.m.
New subject: Shell control through external commands
Traditionally, the shell recognized shell scripts and ran them in a new
instance of the shell rather than calling exec on them.
It was a Berkeley hack to add a new exec magic number that happened to
correspond to the characters #!. The shells typically still recognized
scripts (the #! was syntactically a comment) and invoked them, but if they
were passed to exec (i.e., from something other than the shell that was to
interpret the), the kernel recognized the magic number and invoked what
followed as the name of an interpreter to handle the file.
Not only did this allow arbitrary interpretters (other than /bin/sh or any
shell), but it also allowed things like setuid bits to work, and scripts to
be invoked by things that didn't just feed the file name to a shell to
invoke.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Saturday, September 10, 2016 6:44 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Shell control through external commands
On Sat, 10 Sep 2016, Dario Niedermann wrote:
I never knew that a shell script could work without a
shebang line.
I believe it was used to specify an interpreter other than /bin/sh (the
default).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
2:39 a.m.
New subject: Shell control through external commands
"Ron Natalie" <ron(a)ronnatalie.com> wrote:
Traditionally, the shell recognized shell scripts and
ran them in a new
instance of the shell rather than calling exec on them.
I think that the way the shell "recognized" scripts was by having
exec fail, otherwise how would it know? I think we'll have to go
grubbing in the source archives to be sure.
It was a Berkeley hack to add a new exec magic number
that happened to
correspond to the characters #!.
ISTR reading on this list that #! was a post-V7 Bell Labs invention
that the BSD guys went and implemented themselves...
Can someone who was there please clarify?
Thanks,
Arnold
2:41 a.m.
New subject: Shell control through external commands
On Sep 10, 2016, at 10:39 PM, arnold(a)skeeve.com
wrote:
"Ron Natalie" <ron(a)ronnatalie.com> wrote:
You are correct.
Traditionally, the shell recognized shell scripts
and ran them in a new
instance of the shell rather than calling exec on them.
I think that the way the shell "recognized" scripts was by having
exec fail, otherwise how would it know? I think we'll have to go
grubbing in the source archives to be sure. It was a Berkeley hack to add a new exec magic
number that happened to
correspond to the characters #!.
ISTR reading on this list that #! was a post-V7 Bell Labs invention
that the BSD guys went and implemented themselves...
4:07 a.m.
New subject: Shell control through external commands
On Sat, 10 Sep 2016, arnold(a)skeeve.com wrote:
I think that the way the shell "recognized"
scripts was by having exec
fail, otherwise how would it know? I think we'll have to go grubbing in
the source archives to be sure.
Correct; if the exec failed then the invoking shell assumed that it was a
shell script, and spawned a shell to run it.
With the #! hack, it had to be followed by the full path name (white space
optional) and the kernel ran it directly.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
5:01 a.m.
New subject: Shell control through external commands
Dave Horsfall <dave(a)horsfall.org> wrote:
On Sat, 10 Sep 2016, arnold(a)skeeve.com wrote:
I think this happened in the "spawned" shell - so the exec would fail and
then this child shell would just run the script.
if ((pid = fork()) != 0)
wait for pid
else {
/* in the child */
exec /path/to/program
if (errno == ENOEXEC) /* or whatever it is, I don't remember */
interpret the script directly
}
Arnold
I think that the way the shell
"recognized" scripts was by having exec
fail, otherwise how would it know? I think we'll have to go grubbing in
the source archives to be sure.
Correct; if the exec failed then the invoking shell assumed that it was a
shell script, and spawned a shell to run it.
12 Sep
12 Sep
5:49 a.m.
New subject: Shell control through external commands
On Sat, 10 Sep 2016, arnold(a)skeeve.com wrote:
Oops - you're right. My organic bit-rot is worse than I thought...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Correct; if
the exec failed then the invoking shell assumed that it
was a shell script, and spawned a shell to run it.
I think this happened in the "spawned" shell - so the exec would fail and
then this child shell would just run the script.
2781
days inactive
2841
days old
18 comments
10 participants
participants (10)
-
arnold＠skeeve.com -
Dario Niedermann -
Dave Horsfall -
Doug McIlroy -
markus schnalke -
Ron Natalie -
Ronald Natalie
-
schily＠schily.net -
Sven Mascheck -
Tony Finch