On Aug 5, 2:05 pm, Marc Herbert <marc.herbert+n...@gmail.com> wrote:
> I am not sure I get this... first of all, the script itself is usually
> not read from stdin (but from fd 255 in bash).
>
> Now considering the seldom cases where the script is actually read from
> stdin, are you saying that: it is a wanted feature that subprocesses can
> concurrently slurp and steal the code executed by their parent? Wow,
> that sounds really weird and not something I would wish, but rather a
> design limitation that I should constantly worry about.
>
> Regards,
>
> Marc
Same here, as Marc said.
I think that usually we are reading the script from a file and this is
the use-case we must focus on. Currently, we have the problem I
described when executing a script from a file and I think this must be
fixed/changed.
--Ivan
John Reiser wrote:
On 08/04/2009 12:48 AM, fam...@icdsoft.com wrote:
It is an intended design feature that the shell reads only as much as
necessary
to proceed at the moment. This is required so that subprocesses can
share the same
stdin as the shell. Bytes for input to the shell alternate with bytes
for input
to each subprocess that does not have redirection (or closure) specified
for its stdin.
To avoid this feature, then use the "-c" parameter to specify the entire
shell input
as a string on the command line:
bash -c "$(< filename)"
Or, make a temporary unique copy of the file, then invoke the shell on
the copy.