bug-bash
[Top][All Lists]
Advanced

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

Fwd: Re: EOF at PS2


From: Chet Ramey
Subject: Fwd: Re: EOF at PS2
Date: Tue, 9 May 2023 11:42:08 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1

Forgot to add bug-bash.
--- Begin Message --- Subject: Re: EOF at PS2 Date: Tue, 9 May 2023 11:40:45 -0400 User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1
On 5/4/23 9:52 PM, Martin D Kealey wrote:

    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);

This is relevant to the extent that POSIX specifies ignoreeof, and took
the description from ksh88. If I can dig up a system running ksh88, I'll
see what it does.

and (2) to stop annoying users.

Oh, I don't think Grisha is annoyed. No one else has ever mentioned it.

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"?

I suspect it's never come up. All this stuff was decided in 1989, before
the POSIX standard of it was even published. That was the consensus at the
time.


How many scripts contain "set -o ignoreeof"?

Probably none, since it only works when the shell is interactive.

Of those, how many end without a newline?

The fact is that EOF delimits commands, and everyone agrees on that. I'm
not going to change that behavior.


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

Probably not. I'll look at it at some point.


-Martin

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

    # *ksh --version*
       version         sh (AT&T Research) 93u+ 2012-08-01

Oh, come on. The behavior was in place for more than 20 years by the time
this version was released. ksh88 is the relevant version.

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


--- End Message ---

reply via email to

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