Re: terminating lines with accidental eof

[Bob Proulx]

Please keep your replies to the mailing list to keep everyone involved
in the discussion instead of singling out one individual.  Also the
mailing list is archived and others may search the archive to find
previous discussions.

Martin Wheatley wrote:
> The following can be used to reproduce the problem...
> 
> *     Start an xterm window
> 
> *     "su" to another user in this new xterm window
> 
> *     As this new user enter "touch /tmp/somefile" but do not hit ENTER
> 
> *     kill the xterm where the "su" was entered
> 
> *     The window evaporates but /tmp/somefile now exists!

Thank you for making a small test case example.  I was able to
recreate that behavior on my system too.  I am using the Debian su
based upon the 'shadow' system in the 'login' package.

> Without the "su" there isn't a problem because the shell receives a SIGHUP 
> and doesn't run the command.
> However, with the "su" the SIGHUP cannot be delivered to the shell with the 
> partial command so it gets EOF
> and proceeds to execute what is in its buffer

This really seems like a bug in the su program.  When it receives a
SIGHUP it should pass it on.  Assuming that it is getting a SIGHUP.  I
did not look into the su and signal interaction.

> In reality the xterm may die for any number of reasons (workstation panic, 
> Xserver reset, ...)
> 
> We don't think it is right that any buffered user input should be actioned 
> until the user explicitly requests
> the action (via the ENTER key).

A small point.  You are aware that the tty driver converts enter from
the keyboard into a newline?  See the tty driver 'icrnl' flag setting.
Programs never read a carriage return.  Programs actually read a
newline character.

This would, of course, break legacy programs which do not terminate
their input with a newline.

> The concept of entering commands with a # at the start is well known to 
> computing staff but to educate all users
> (bothe technical and non-technical) around the world of this issue is not 
> realistic.

It is a behavior gained by experience.  Experience has sometimes been
desribed as being the toothmarks left behind after being bitten.  I
suggested it because it is what I normally do when I am concerned
about that a command may be accidentally executed before I am ready to
execute it.

> This is not a hypothetical situation - a user had "su'ed" and pre-typed a 
> command and was waiting for permission to executed the command
> when the xterm window was accidentally killed by another user and the 
> buffered input was executed - resulting in unscheduled (and costly) 
> shutdown of some
> of our plant equipment.

Thank you for providing that real world example.

> Surely the argument should not be as to whether the situation can or cannot 
> happen (for whatever reason) - it clearly can (as we have experienced) and
> the code should be fixed to prevent this happening at all.

Until you provided the example and the report of an actual occurrence
there was no reason to believe this had ever happened.

It is a continuing challenge to keep the system design functioning in
good ways.  It is a judgement call in most cases.

I believe it was Andrew Koenig who proposed this thought problem.
Have you ever cut yourself on a kitchen knife?  Most of us have at one
time or another.  Can you design a knife so that it is now impossible
to injure yourself with it?  How effective will this new design be in
the kitchen?  Would you use such a knife yourself?

I feel for you in the situation that you described.  But I also feel
that the user you mentioned pulled out a kitchen knife to cut some
vegetables.  They were holding it in their hand prepared and waiting
to start chopping when someone accidentally bumped into them from
behind when they were not looking.  Because of this they cut something
they did not want to cut with the knife they were holding.

There is only so much that can be done to make the world a safe place.
I personally do not see any way to improve bash in this area.  And in
addition to bash there are many other shells such as sh, ksh, zsh,
csh, tcsh, ash, etc.  You would need to change the behavior of all of
them.

Bob