[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
>
- Re: EOF at PS2, Chet Ramey, 2023/05/03
- Message not available
- Fwd: EOF at PS2,
Martin D Kealey <=