bugThe GNU Bourne-Again SHell - Bugs: bug #67045, bash parsing error, when using...

 
 

bug #67045: bash parsing error, when using readline, backslashes, and <Ctrl-d>

Submitter:  None
Submitted:  Tue 22 Apr 2025 08:41:19 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 25 Apr 2025 07:19:40 PM UTC, comment #3: 

On 4/24/25 2:36 AM, anonymous wrote:

> Follow-up Comment #2, bug #67045 (group bash):
>
> comment #1:
>> The current version of bash (bash-5.3-rc1 as well as the bash devel git
>> branch) no longer behaves this way.
>>
>> The current behavior is to execute the partial command, as if the shell has
>> read newline, then exit on the EOF. This is consistent with historical sh
>> behavior and is what a number of other shells do. (To be fair, behavior here
>> varies widely.)
>
> I checked, and you are right, that particular one is fixed, but not the whole
> family of them, especially if we throw heredocs in the mix


I see that you want `sticky' EOFs.


> $ cat << EOF\<Return>
>> <Ctrl-D>


This is not treated as an EOF, since it does not appear as the first
character on the line from the shell's perspective (remember that the
backslash-newline disappears). It simply delimits the token. If it's a
`real' EOF, the next read will return EOF again. This is also how you
process `ignoreeof', by the way.


>> world<Return>
>> <Ctrl-D>
> bash: warning: here-document at line 2 delimited by end-of-file (wanted
> `EOF')
> world


This is treated as an EOF, since it appears as the first character on a
line, and there's no token to delimit.

> $ <Up arrow for history>
> $ cat << EOFworld


Is this the bug you're trying to report? The history entry created by the
command-oriented history code?


Chet Ramey <chet>
Group administrator
Thu 24 Apr 2025 06:36:46 AM UTC, comment #2: 

comment #1:

> The current version of bash (bash-5.3-rc1 as well as the bash devel git branch) no longer behaves this way.
>
> The current behavior is to execute the partial command, as if the shell has read newline, then exit on the EOF. This is consistent with historical sh behavior and is what a number of other shells do. (To be fair, behavior here varies widely.)


I checked, and you are right, that particular one is fixed, but not the whole family of them, especially if we throw heredocs in the mix

$ cat << EOF\<Return>
> <Ctrl-D>
> world<Return>
> <Ctrl-D>
bash: warning: here-document at line 2 delimited by end-of-file (wanted `EOF')
world
$ <Up arrow for history>
$ cat << EOFworld


(tested on bash 5.3-rc1)

Anonymous
Wed 23 Apr 2025 03:28:33 PM UTC, comment #1: 

The current version of bash (bash-5.3-rc1 as well as the bash devel git branch) no longer behaves this way.

The current behavior is to execute the partial command, as if the shell has read newline, then exit on the EOF. This is consistent with historical sh behavior and is what a number of other shells do. (To be fair, behavior here varies widely.)

Chet Ramey <chet>
Group administrator
Tue 22 Apr 2025 08:41:19 PM UTC, original submission:  

When using readline, this happens


$ echo hello\<Return>
> <Ctrl-d>
> world<Return>
hello world
$ <Up arrow for history>
$ echo helloworld


Note, there is no issue when backslash is a word by itself

$ echo hello \
> <Ctrl-d>
hello
[Bash exits here]


After some debugging, I understood, that this happens because of shell_getc, and eventually yy_readline_get multiple times in the case of a word ending in \, and because readline can continue working after getting a <Ctrl-D> (read of 0 bytes), I propose putting a flag, and not call readline after having gotten 0 bytes. I am attaching a proposed patch

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57157:  readline_eof_fix.patch added by None (947B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-04-23 chet StatusNone Fixed
    2025-04-22 None Attached File- Added readline_eof_fix.patch, #57157

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code