Date: Mon, 8 Apr 2024 12:32:13 +0300
From: =?UTF-8?B?T8SfdXo=?= <oguzismailuy...@gmail.com>
Message-ID:
<cah7i3lqng7snjvobgw9gcfw_tka1kfvn+pv7h+bvktotu7i...@mail.gmail.com>
| The only ash clone that does this is gwsh, all others print "a" and a
| command-not-found error.
I have (today, after your e-mail) changed the NetBSD shell so it works
like is (apparently) required (no real code ever seems to be affected):
jacaranda$ ./sh <<eof
echo a
read x
b
echo \$x
eof
a
b
That is not committed yet (just my private copy) - but will be once
I have finished some unrelated changes (bogged down a bit by needing
to be documented!)
However, this "fix" is a special case for "read" where there is about
a one in a trillion possibility that someone might want to actually
do something like that in real code.
For other (normal) utilities (ones not built into the shell, read is
the only built-in, at least in our shell, which accesses its stdin),
this part of the quoted section makes the whole thing useless:
or that characters that are not read by the invoked command
are not seen by the shell.
The problem is that the script writer has no way to predict just
how many characters will be read by the invoked command, it doesn't
necessarily have anything to do with how much that command processes.
There is in general no spec that suggests that commands not use
stdio for input, and when reading, stdio generally buffers some random
unspecified amount, and reads a buffer load from the file. All
perfectly permitted (except for the read command in the shell which
isn't allowed to do that).
The effect is that sharing stdin between the shell script, and other
commands (than read), is almost certainly never going to work, so I'm
not even going to consider doing more than what was done for the above
(which just caused the read builtin, when reading from the script file,
to share the shell's input buffer, taking whatever it needs, after which
the shell continues with whatever follows.)
kre
