Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14570 > unrolled thread

Re: History of bash's support for self-modifying shell scripts?

Started byRobert Elz <kre@munnari.OZ.AU>
First post2018-09-11 10:19 +0700
Last post2018-09-11 10:19 +0700
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: History of bash's support for self-modifying shell scripts? Robert Elz <kre@munnari.OZ.AU> - 2018-09-11 10:19 +0700

#14570 — Re: History of bash's support for self-modifying shell scripts?

FromRobert Elz <kre@munnari.OZ.AU>
Date2018-09-11 10:19 +0700
SubjectRe: History of bash's support for self-modifying shell scripts?
Message-ID<mailman.621.1536636010.1284.bug-bash@gnu.org>
    Date:        Tue, 11 Sep 2018 01:11:41 +0200
    From:        =?ISO-8859-1?Q?=C1ngel?= <angel@16bits.net>
    Message-ID:  <1536621101.1095.13.camel@16bits.net>

  | The Thompson shell (up to Sixth Edition UNIX) supported a goto command
  | that was implemented as an external command(!) that moved the
  | filepointer to the label location (marked by the : command).

What is probably more important here is that in that shell, the script was 
standard input (always, whether it was a file as in "sh file" or just the
original stdin (often a tty) from "sh") and all foreground commands
inherited that standard input when invoked, unless redirected.
(Yes, just running "cat" without args was a way to send the rest of
the script to stdout, and then have the shell exit because it reached EOF.)

Any command could reposition the shell's stdin, which made it possible
to do all kinds of "interesting things".

On the other hand, it was impossible to pipe the output of some other
command into a script
	ls ^ sh file
would not work (note the use of the v6 "pipe" character...) as the sh
running the script simply closed its stdin and replaced it with the file.
Redirecting stdin ("sh file < whatever") was also ineffective.

These days there is no syntax to refer to the script itself - it is impossible
to explicitly pass the script to a command to access - the only time any
of this is still relevant is when the shell's input is from stdin (sh -s,
whether the -s is explicit or implied from the (lack of) other args).

kre

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web