don't just seek to the next line if the script has been edited

[jid...@jidanni.org]

Let's say you are running a script that is doing
a loop while ... echo Enter name; read name; ..

During which the script gets edited on the disk by somebody.

Well shouldn't bash, when it goes back to the disk to read some next
part of the script, first do some sort of check to tell if the script has
changed on disk, instead of the current behavior which apparently is to
seek() to the former byte number and execute the next line which now
very well might be halfway lodged inside some comment or something.

[Pierre Gaston]

That has been discussed on help-bash recently
http://lists.gnu.org/archive/html/help-bash/2013-05/msg00046.html

My opinion is that it's reasonable to have no expectation as to what
should happen if you edit a script while it's running.
I don't think it's a great idea to slowdown bash to check if, when
running from a file, it has changed, or to use non-buffered input .

[jid...@jidanni.org]

Well OK but sometimes a script could be running for years, during which
any change to a file will result in bash executing random bytes...

Imagine if you press down on the mouse button meanwhile someone moves
the screen up or down... you end up pressing on a different person's
face.

So I don't see any case where allowing this adds any value to bash.
In fact I don't recall any other program with such scary behavior.

I mean it's fine with me if bash will execute my script version 1, or my
script version 2, but not some mishmosh of random bytes.

Surely a little itty bitty check can't slow things that much down.

So if I were bash I would bail out "$0 changed on disk. Bailing out
rather than executing random bytes."

[Greg Wooledge]

On Fri, Jun 07, 2013 at 09:09:53PM +0800, jid...@jidanni.org wrote:
> Well OK but sometimes a script could be running for years, during which
> any change to a file will result in bash executing random bytes...

This is why you don't edit an installed script in-place. Instead, you
move it aside, or remove it, or hardlink it, or do some other fancy thing.


# This is the naive way. It is bad because an already-running shell reading
# the script as input may get garbled text. Also, there is a period of
# vulnerability where the new script is only partially written to disk;
# anyone running the script at that time may just get part of it. Finally,
# the old script is not preserved, so if the OS crashes during the copy,
# you have neither the old one nor the new one.

cp myscript /usr/local/bin


# This looks better at first glance, and it dodges the problems of mixing
# old and new text in an already-running shell, but it leaves a period of
# vulnerability where there's no installed script, or where there's a
# partially installed script, and it doesn't prevent loss of the old script
# if the OS crashes during the copy. So, this is still bad.

rm /usr/local/bin/myscript && cp myscript /usr/local/bin


# This one is only slightly better. It preserves the old script in case
# the OS crashes during the copy, which allows for manual rollback, but
# it still leaves that vulnerable period where someone could invoke the
# script while it's only partially copied.

mv /usr/local/bin/myscript /usr/local/bin/myscript.bak &&
cp myscript /usr/local/bin


# This is better. The mv is atomic, so there is no period of vulnerability
# during which the script is either missing or partially installed.

cp myscript /usr/local/bin/myscript.tmp &&
mv /usr/local/bin/myscript.tmp /usr/local/bin/myscript


# Alternative, maintaining several installed versions on disk simultaneously.
# The installed "script" is really a symlink. The ln is atomic, so this
# also avoids all the issues, as long as you never use the same version
# number more than once.

cp myscript /usr/local/bin/myscript-some.version.number &&
ln -sf myscript-some.version.number /usr/local/bin/myscript

[jid...@jidanni.org]

>>>>> "GW" == Greg Wooledge <woo...@eeg.ccf.org> writes:

GW> On Fri, Jun 07, 2013 at 09:09:53PM +0800, jid...@jidanni.org wrote:
>> Well OK but sometimes a script could be running for years, during which
>> any change to a file will result in bash executing random bytes...

GW> This is why you don't edit an installed script in-place. Instead, you
GW> move it aside, or remove it, or hardlink it, or do some other fancy thing.

Well it is going to happen anyway, so maybe bash should check by
default, and not check if -o risky is set or something. It can't be that
expensive.

[Greg Wooledge]

On Fri, Jun 07, 2013 at 10:15:46PM +0800, jid...@jidanni.org wrote:
> Well it is going to happen anyway, so maybe bash should check by
> default, and not check if -o risky is set or something. It can't be that
> expensive.

Yes it can. You're talking about adding a ridiculous amount of extra
checking and performance penalty to try to avoid users shooting themselves
in the foot *on Unix*.

As far as I'm concerned, the correct solution is to educate the users
instead. I don't speak for Chet, of course.

[Gerard Seibert]

On Fri, 7 Jun 2013 10:19:44 -0400
Greg Wooledge articulated:

> Yes it can. You're talking about adding a ridiculous amount of extra
> checking and performance penalty to try to avoid users shooting
> themselves in the foot *on Unix*.

The job of the OS is not to prevent a user from shooting themselves in
the foot, but rather to deliver the bullet as efficiently as possible.

--
Gerard ✌
ger...@seibercom.net

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________

[jid...@jidanni.org]

>>>>> "GW" == Greg Wooledge <woo...@eeg.ccf.org> writes:

GW> You're talking about adding a ridiculous amount of extra checking
GW> and performance penalty to try to avoid users shooting themselves in
GW> the foot *on Unix*.

I dunno... I thought it might be just reading a couple bytes from where
the date is stored before reading a lot more bytes from where the data
is stored. But what do I know.

[Chet Ramey]

The current bash behavior is described in

http://lists.gnu.org/archive/html/help-bash/2013-05/msg00049.html

There are certain obscure cases where this can cause problems on Unix due
to parent/child sharing of file offset pointers.

I think the correct solution is to retain this behavior where it is
required (e.g., when reading a script from the standard input) and to
discard it when reading a script from a file. This doesn't directly
address the jidanni's concern, but I think the actual occurrence of this
problem is infrequent enough to not do anything more elaborate.

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

[Chet Ramey]

On 6/7/13 10:48 AM, Gerard Seibert wrote:
> On Fri, 7 Jun 2013 10:19:44 -0400
> Greg Wooledge articulated:
>

>> Yes it can. You're talking about adding a ridiculous amount of extra
>> checking and performance penalty to try to avoid users shooting
>> themselves in the foot *on Unix*.
>

> The job of the OS is not to prevent a user from shooting themselves in
> the foot, but rather to deliver the bullet as efficiently as possible.

Bash will not stop a user from shooting himself in the foot. If asked, it
will obediently load the gun.

[jid...@jidanni.org]

>>>>> "CR" == Chet Ramey <chet....@case.edu> writes:
CR> I think the correct solution is to retain this behavior where it is
CR> required (e.g., when reading a script from the standard input) and to
CR> discard it when reading a script from a file. This doesn't directly
CR> address the jidanni's concern, but I think the actual occurrence of this
CR> problem is infrequent enough to not do anything more elaborate.

All I know is there I am in emacs seeing things in the output of a
running bash script that I want to tweak and get busy tweaking and saving
changes before the script finishes, thinking that all this stuff will be
effective on the next run of it, when lo and behold now it begins
executing random bytes... Yes one can say that these are not C programs
and one needs to revise ones expectations, but still I think some
parental safety cap is required to keep it from munching random bytes
which will always be wrong... such overly dynamic-ness can never be a
feature and always be a wild incident unless one gets the alignment just
right etc. etc.

Anyway my problem is always for scripts on disk and not for the stdin
case so maybe I'm covered by the coming changes.

[Linda Walsh]

jid...@jidanni.org wrote:

> All I know is there I am in emacs seeing things in the output of a
> running bash script that I want to tweak and get busy tweaking and saving
> changes before the script finishes, thinking that all this stuff will be
> effective on the next run of it, when lo and behold now it begins
> executing random bytes... Yes one can say that these are not C programs

----
If they were C programs, and you were to edit binary in place, while it was
executing, using memory-mapped I/O, the machine might very well start executing
garbage and your C program would dump core or similar.

Chances are, your text editor is writing to the same file as it read from
rather than writing your program to a new file and moving the old off to a
backup.

If your text editor always stored your new input in a new file you wouldn't
see this behavior. Emacs is supposed to be configurable .. I know vim will
do different things based on if the file has hard links or not (it will try
not to break them, otherwise it's a new file each time)...

[Mike Frysinger]

On Sunday 09 June 2013 16:59:15 Linda Walsh wrote:
> jid...@jidanni.org wrote:
> > All I know is there I am in emacs seeing things in the output of a
> > running bash script that I want to tweak and get busy tweaking and saving
> > changes before the script finishes, thinking that all this stuff will be
> > effective on the next run of it, when lo and behold now it begins
> > executing random bytes... Yes one can say that these are not C programs
>
> ----
> If they were C programs, and you were to edit binary in place, while it was
> executing, using memory-mapped I/O, the machine might very well start
> executing garbage and your C program would dump core or similar.

pretty sure the linux kernel (and others?) would return ETXTBSY and not even
allow the write
-mike

[Linda Walsh]

Mike Frysinger wrote:
> pretty sure the linux kernel (and others?) would return ETXTBSY and not even
> allow the write

----
I think that's a relatively new innovation -- i.e. since
the ability to setup read-only code segments was implemented,
though FWIW, you are right.

I think it's a text editor thing --
for Example, on windows, I can't write to a running
bash-script (says it is read-only for the duration of execution.
Though I can on linux.

I suppose if bash were to mmap the script file and mark
it as "executable", it would get the same read-only protection as
binaries..??