[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: History of bash's support for self-modifying shell scripts?
Date: Mon, 10 Sep 2018 16:50:29 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 9/10/18 1:25 AM, Josh Triplett wrote:
> While digging into the details of how bash reads shell scripts, I found
> some indications that bash goes out of its way to support self-modifying
> shell scripts. As far as I can tell, after reading and executing each
> command, bash will seek backward and re-read the script from the
> byte after the end of that command, rather than executing out of
> buffered data previously read from the file. (For the purposes of this
> logic, compound commands get run as a single unit, and this logic kicks
> in after running the full compound command.)

It happens in only a few cases: 1) when forking a child to run a command;
2) when a redirection specifies the same file descriptor as bash is using
to read a script; and 3) when bash is reading a script from stdin and the
read builtin is used to read from that file descriptor.

The first case is probably the one you're interested in. It's been there
even since I wrote the buffered input code in 1992, and it's more about
making sure parent and child shells have a consistent view of the script
in case the child expects to read from it. It's about being careful, not
explicitly allowing self-modifying scripts.

Previous versions of the shell (through bash-1.12) used stdio, which has
behavior that varies across systems, especially across parent-child
boundaries and changing file descriptors due to redirection (which it can't
really handle at all).

POSIX says you have to do that anyway if the shell is reading from stdin:

"When the shell is using standard input and it invokes a command that also
uses standard input, the shell shall ensure that the standard input file
pointer points directly after the command it has read when the command
begins execution. It shall not read ahead in such a manner that any
characters intended to be read by the invoked command are consumed by the
shell (whether interpreted by the shell or not) or that characters that are
not read by the invoked command are not seen by the shell."

But it probably isn't needed in the general case. Why not take the code out
and see what happens with your testing?

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]