patchThe GNU Bourne-Again SHell - Patches: patch #10360, uninvited interactive input...


You are not allowed to post comments on this tracker with your current authentication level.

patch #10360: uninvited interactive input terminates recursive shells while expecting a completion of a Unicode codepoint

Submitter:  Ilguiz Latypov <ilgiz>
Submitted:  Thu 22 Jun 2023 11:46:19 PM UTC
Category:  None Priority:  5 - Normal
Status:  Works For Me Privacy:  Public
Assigned to:  None Open/Closed:  Open

Jump to the original submission

Wed 30 Aug 2023 03:13:46 PM UTC, comment #6: 

(To add confusion, sed interprets its regex [\xNN] depending on the locale.  Using Bash expansion of $'\xNN' and of $'\\' as sed literal matches, the ambiguity can be resolved).

$ printf '\x80' | LANG=en_US.UTF-8 sed -e $'s/\x80/\\\\x80\\n/g'

$ printf '\x80' | LANG=C sed -e $'s/\x80/\\\\x80\\n

Ilguiz Latypov <ilgiz>
Tue 29 Aug 2023 11:10:34 PM UTC, comment #5: 

Thank you, Chet.  Running just printf,

$ LANG=en_US.UTF-8 printf '\x80'

stalls the console and terminates it on receiving arbitrary keyboard character if I run a pipe before it, such as "echo a | cat".

The behaviour appears correct in a GUI Windows Terminal from Microsoft Store.  A Unicode "replacement character" with a question mark inside (0xFFFD) is shown by the terminal if sed passes the input unmodified due to the locale requiring complete UTF-8 sequences.

$ LANG=en_US.UTF-8 printf '\x80'

$ printf '\x80' | LANG=C sed -e 's/[\x80]/\\x80\n/g'

$ printf '\x80' | LANG=en_US.UTF-8 sed -e 's/[\x80]/\\x80\n/g'

Case closed.

Ilguiz Latypov <ilgiz>
Fri 30 Jun 2023 04:21:56 PM UTC, comment #4: 

So this only happens in an old version of Windows Console? Using a program that outputs an incomplete unicode codepoint? And `cat -v', which outputs non-ascii characters as ascii sequences, makes the problem go away?

My guess is that the windows terminal emulator is making some assumptions about unicode characters and crashing as a result.
It slaughters the processes running it it to the degree that they don't even have a chance to run exit traps.

What happens when you just run the printf?

dash isn't a good example because it doesn't understand multibyte characters, much less unicode, at all.

Chet Ramey <chet>
Group administrator
Thu 29 Jun 2023 05:58:16 PM UTC, comment #3: 

Also, starting an interactive dash in the same WSL terminal/bash session resolves the lockups/disappearances.

Ilguiz Latypov <ilgiz>
Wed 28 Jun 2023 07:01:15 PM UTC, comment #2: 

On one hand, I can reproduce this only in the WSL console (the original terminal implemented as a Windows Console app not the latest multi-tab terminal, which I did not try).  Attempting to reproduce this with the same bash and sed versions in a remote Linux box under its tmux terminal fails.

On the other hand, I would think that a failure in sed would not cause silent termination or lock-up of the parent shell that runs the pipe or the grandparent interactive shell or the great-grandparent Windows terminal.

Ilguiz Latypov <ilgiz>
Mon 26 Jun 2023 08:33:13 PM UTC, comment #1: 

I can't reproduce this on macOS using Terminal, or when using macOS and Terminal to ssh to a RedHat box.

If you change from sed to cat in the second pipeline element and the problem goes away, doesn't that imply that the problem is with sed? Whether it outputs something that causes the terminal to exit or somehow causes reads to fail?

Chet Ramey <chet>
Group administrator
Thu 22 Jun 2023 11:46:19 PM UTC, original submission:  

My terminal terminates when a pipe's reader fails to complete reading a Unicode codepoint.  I am not sure it is bash's fault.

It happens when I hit Ctrl+C after the pipe's writer completes.  It also happens when I hit Enter.

GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

$ # Works all right with LANG=C
$ { printf '\x80'; sleep 2; } | LANG=C sed -e 's/[\x80]/\\x80/g'

$ # With LANG=en_US.UTF-8, the interactive shell and its
$ # parent terminal die bypassing any traps if, after the
$ # completion of the pipe writer, I press Enter or hit Ctrl+C.
$ { printf '\x80'; sleep 2; } | LANG=en_US.UTF-8 sed -e 's/[\x80]/\\x80\n/g'

The terminal remains with its interaction blocked if sending SIGINT from the original shell.

$ { { printf '\x80'; sleep 2; } | LANG=en_US.UTF-8 sed -e 's/[\x80]/\\x80\n/g' ; } & { sleep 1; echo sending SIGINT to $! from $$; ps wwwft; kill -s SIGINT $!; }
[1] 2775
sending SIGINT to 2775 from 2773
 2773 pts/6    Ss     0:00 -bash
 2775 pts/6    S      0:00  \_ -bash
 2776 pts/6    S      0:00  |   \_ -bash
 2779 pts/6    S      0:00  |   |   \_ sleep 2
 2778 pts/6    S      0:00  |   \_ sed -e s/[\x80]/\\x80\n/g
 2780 pts/6    R+     0:00  \_ ps wwwft

Changing "sleep 3" to "sleep 1" keeps the terminal as well but does not show even the echo before locking up the terminal.

$ { { printf '\x80'; sleep 2; } | LANG=en_US.UTF-8 sed -e 's/[\x80]/\\x80\n/g' ; } & { sleep 3; echo sending SIGINT to $! from $$; ps wwwft; kill -s SIGINT $!; }
[1] 2785

Using "cat -v" instead of "sed" does not destroy or lock up the terminal, regardless of LANG.

Ilguiz Latypov <ilgiz>


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

No files currently attached


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)
  • -email is unavailable- added by ilgiz (Submitted the item)

    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.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-06-26 chet StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code