bug-bash
[Top][All Lists]
Advanced

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

Re: EOF at PS2


From: Chet Ramey
Subject: Re: EOF at PS2
Date: Wed, 3 May 2023 15:20:25 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1

On 4/26/23 5:38 PM, Grisha Levit wrote:
A few issues with EOF being received at PS2:


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.

In the command above, the \<newline> is removed, the lexer returns EOF as
the token (since it's looking for a new token, the previous token having
been delimited), and the EOF delimits the command, as it always has. This
is historical sh behavior -- the Bourne shell used to let EOF delimit all
sorts of things, e.g., command substitution.

Since the simple command is well-formed and the EOF is a valid command
terminator, the command executes. EOF terminating commands is how the shell
can execute scripts that don't end with a newline, or how you make -c work
without too many special cases.

Since the shell saw EOF as a separate token, the reader loop breaks and the
shell exits.

If the previous line didn't terminate the current token, ^D causes the
token (rather than the command) to be terminated and a new PS2 to be
printed. The history code treats them as one word.

Right. Once you're in the middle of reading a token, EOF delimits the token
but is otherwise discarded. This is also historical bash behavior, in there
since the late 1980s as well.

For non-interactive shells, this isn't usually an issue: once you read EOF,
you're likely to get EOF again on the next read, so once you go back to get
the next token, you get EOF and everything works. But if you go back to
read a new token and you get something that's not EOF, like you have here,
the shell just keeps going.


bash --norc
$ echo A\
^D
B
A B
$ !!
echo AB
AB

So the \<newline> disappears, the ^D delimits the token, there is more
input (the EOF is not `sticky', if you will), but the history code doesn't
know that EOF did anything, since it's text-based, not token-based. The
shell doesn't translate EOF into a space or anything.

And perhaps most surprising, if PS0 contains a command substitution,
the wrong prompts are shown:

Now, that's interesting. I'll take a look sometime.

--
``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/




reply via email to

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