GNU bug report logs - #67259
29.1; shell/term behavior different from other terminal emulators

Previous Next

Full log

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Max Nikulin <manikulin <at> gmail.com>
To: Matt <matt <at> excalamus.com>, bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>
Subject: Re: 29.1; shell/term behavior different from other terminal emulators
Date: Sun, 30 Jun 2024 16:52:14 +0700

On 18/11/2023 16:55, Matt wrote:
> I'm helping to maintain Org mode's shell interaction.  The following
> was reported to the Org list.

When I noticed a discussion of dash bug causing difference in comparison 
to bash for the provided input, I have realized that Org babel shell 
issue and this emacs bugs are unrelated. This one is specific to 
interactive sessions.

> Emacs M-x shell and M-x term executing in term-line-mode both produce
> a different result

Likely `shell' and `term' issues should be treated separately and this 
bug should be cloned.

>  than expected as compared to terminal emulators
> like xterm or xfce4-terminal running Bash.  For non-Emacs terminal
> emulators, "bar" is echoed.  M-x shell and M-x term executing in
> term-line-mode do *not* echo "bar".
> 
> To reproduce with M-x shell:
> 
> 1. emacs -Q
> 2. M-x shell
> 3. Copy the following two lines:
> 
> ssh localhost "echo foo>foo_file"
> echo "bar"

I think the following allows to eliminate ssh and to demonstrate the 
issue with purely local commands. (BASH on macOS might be too old)

    fakessh() {
        bash -c 'read -t 0.2 -r; printf "fakessh read: %s\n" "$REPLY"';
    }

    fakessh
    echo next

result:

    fakessh read: echo next

instead of

   fakessh read:
   next

likely expected by users because it is behavior of xterm&Co.

since `shell' relies on specific terminal type, to get the same result 
on pasting whole snippet at once, do in xterm or a similar application

    TERM=dumb bash

With default TERM modern terminal applications and shells have bracketed 
paste enabled. It is a security measure that allows users to review 
pasted commands before executing them

<https://security.stackexchange.com/questions/39118/how-can-i-protect-myself-from-this-kind-of-clipboard-abuse>

When bash is running outside of Emacs, it is possible to paste multiple 
commands into an editor, try C-x C-e in bash prompt.

In my opinion, `shell' either should be documented as unsafe with 
warnings in docstring and manual or some workaround should be 
implemented, e.g. saving paste text into a temporary file and executing 
them.

> To reproduce with M-x term:
> 
> 1. emacs -Q
> 2. M-x term
> 3. C-c C-j to switch to term-line-mode

Notice that `term' is not affected if `term-line-mode' is not activated.

> 4. Copy the following two lines:
> 
> ssh localhost "echo foo>foo_file"
> echo "bar"

Another option to break xterm that might be closer to `term-line-mode':
Create a custom inputrc file, e.g./tmp/disable-paste.inputrc

    $include /etc/inputrc
    set enable-bracketed-paste off

and run e.g. in xterm

     INPUTRC=/tmp/disable-paste.inputrc bash

The result pasting the bunch of commands at once is

    fakessh read: echo next

I think, input from `term-line-mode' should be treated more closely to 
bracketed paste.

As a final remark, be careful with scripts running commands like ssh or 
ffmpeg that optionally read stdin. Be explicit with your intentions and 
either do

    fakessh </dev/null
    echo next

or

    fakessh <<"EOF"
    echo next
    EOF

depending on desired result.
<https://mywiki.wooledge.org/BashFAQ/089>
"I'm reading a file line by line and running ssh or ffmpeg, only the 
first line gets processed!"

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.