bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: EOF at PS2


From: Martin D Kealey
Subject: Fwd: EOF at PS2
Date: Fri, 5 May 2023 11:54:04 +1000

On Thu, 4 May 2023 at 05:20, Chet Ramey <chet.ramey@case.edu> wrote:

> On 4/26/23 5:38 PM, Grisha Levit wrote:
> > The setting of ignoreeof is ignored at PS2:
> >
> > bash --norc -o ignoreeof
> > $ uname \
> >> ^D
> > Linux
> > (bash exits)
>

It's never been active in this situation, because it doesn't meet the
> criteria for ignoreeof: EOF on an empty line without any command. Bash
> has always done this, dating back to the late 1980s, and I don't see any
> reason to change that here.
>

How about these for reasons: (1) to bring it into line with what ksh does
(even without ignoreeof, ksh does not exit there); and (2) to stop annoying
users.

The current behaviour seems like a backwards reading of the meaning of
"ignoreeof causes EOF to be ignored at the beginning of a command": yes,
ignoreeof should indeed only change the behaviour at the beginning of a
command, but I submit that ksh has it right: anywhere else EOF should
*never* trigger an immediate exit.

If it's reading anything other than a TTY, then it will of course find EOF
again at the beginning of the next command, and *that* should be where the
exit occurs.

If it's reading from a TTY, this change will remove an irritation for users
who find sessions unexpectedly terminated. If there are a few users who are
surprised by this change, they will at worst have to hit ^D twice.

The current behaviour might be longstanding, but is it actually justified?
What practical use is an 'ignoreeof' setting whose real meaning is "oh, but
go ahead and exit anyway if you happen to be in the middle of a command"?

How many scripts contain "set -o ignoreeof"? Of those, how many end without
a newline? Of those, how many could observe a difference in behaviour with
this change? (Maybe some crazy self-modifying script exists somewhere, but
I can't imagine such a thing being particularly stable if it's relying on a
*failure*.

Would even a single person be negatively impacted by fixing this?

-Martin

PS: this isn't new; I'm looking at:

> # *ksh --version*
>   version         sh (AT&T Research) 93u+ 2012-08-01
>
# *dpkg -l ksh*
> ...
> ||/ Name             Version       Architecture  Description
>
> +++-================-=============-=============-=====================================
> ii  ksh              93u+20120801- amd64         Real, AT&T version of the
> Korn shell
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]