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

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

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

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? Chet Ramey <chet.ramey@case.edu> - 2018-09-11 10:05 -0400

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

On 9/10/18 5:39 PM, Josh Triplett wrote:

>> 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.
> 
> Interesting. I don't *think* the behavior I observed corresponds to one
> of those cases; I observed it by just having a shell script that
> carefully used `dd conv=notrunc of=$0 ...` to write code into the
> current script after the current command.

That seems to be exactly the first case: forking a child to run a command.
In this case, the command as written is a command substitution.

> 
>> 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."
> 
> I did find that, but that only applies to stdin, not to shell scripts.

That's not exactly what I think you mean to say; this should certainly
produce `output' on stdout

cat
output

when fed to the shell as a script on stdin (and the `cat' should consume
the rest of the script as input).

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

[toc] | [standalone]

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

csiph-web