On Sat, 29 Dec 2018, Chet Ramey wrote:
http://lists.gnu.org/archive/html/bug-bash/2018-09/msg00023.html
Not sure if I understood everything, so allow me to quote you,
from
http://lists.gnu.org/archive/html/bug-bash/2018-09/msg00024.html
... 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.
What occurred to me is the following: suppose a script s1 starts
being executed, by forking say, and then s1 is overwritten; bash
detects this and re-reads the file. OK, then exactly where does
bash continue executing the script s1 if changes were made
throughout the file, even before the current location pointer?
(in relative terms, of course)
Does it count the number of bytes? The number of records?
I cannot see any consistent way. It seems impossible, in
general, to avoid at least one of the following cases:
(1) executing commands that are present in at least one of
the files, but which (in a given situation) wouldn't be
executed if either file were to be run as a whole
(2) executing commands that are *not* present in either file
(ie, the older and newer versions of s1), for example
"garbage" commands that make the execution abort
Both cases may lead, for instance, to the deletion of files
that had never been intended to be deleted, and so on...
And that, if true, would make your consistency argument kind
of secondary, so to say (in my opinion, of course).
Best regards,
Paulo Nogueira
