info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
5.1.0(1)-release (x86_64-redhat-linux-gnu) - bash -l behavior chane
76 views
Skip to first unread message
Ted Lyngmo
May 25, 2021, 4:48:28 PM5/25/21
to
The origin of my question: https://stackoverflow.com/questions/67674633/fedora-34-pasting-multiple-commands-into-a-bash-terminal-behavior-change
After upgrading from Fedora 33 (bash 5.0.17(1)-release) to 34 (bash 5.1.0(1)-release) the shell behaves odd. When pasting to shell, the pasted text is automatically marked, as if selected and it breaks earlier behavior. Pasting this:
```
echo first $SHLVL
bash
echo $SHLVL
bash
echo $SHLVL
exit
echo $SHLVL
exit
echo last $SHLVL
```
would in a fresh login session in bash 5.0.17 print "first 1", "2", "3", "2", "last 1". In 5.1.0 nothing happens until you press return after the paste - and then you find yourself in SHLVL 2 or 3. The sequence is not executed. Sometimes, SHLVL says 2 - and "pstree -alps $$" confirms that the original bash login shell is owning the current shell - yet "exit" will exit the login session completely.
The workaround I've found for this odd behavior is to add the following in my .bashrc:
oldterm=$TERM;export TERM=dumb;export TERM=$oldterm;unset oldterm
This seems to set the login shell in a mode that acts like it previously did.
Is this know? Deliberate? If this is "as designed", is there an option to turn it off?
After upgrading from Fedora 33 (bash 5.0.17(1)-release) to 34 (bash 5.1.0(1)-release) the shell behaves odd. When pasting to shell, the pasted text is automatically marked, as if selected and it breaks earlier behavior. Pasting this:
```
echo first $SHLVL
bash
echo $SHLVL
bash
echo $SHLVL
exit
echo $SHLVL
exit
echo last $SHLVL
```
would in a fresh login session in bash 5.0.17 print "first 1", "2", "3", "2", "last 1". In 5.1.0 nothing happens until you press return after the paste - and then you find yourself in SHLVL 2 or 3. The sequence is not executed. Sometimes, SHLVL says 2 - and "pstree -alps $$" confirms that the original bash login shell is owning the current shell - yet "exit" will exit the login session completely.
The workaround I've found for this odd behavior is to add the following in my .bashrc:
oldterm=$TERM;export TERM=dumb;export TERM=$oldterm;unset oldterm
This seems to set the login shell in a mode that acts like it previously did.
Is this know? Deliberate? If this is "as designed", is there an option to turn it off?
Ted Lyngmo
May 26, 2021, 11:02:34 AM5/26/21
to
> The origin of my question: https://stackoverflow.com/questions/67674633/fedora-34-pasting-multiple-commands-into-a-bash-terminal-behavior-change
>
> After upgrading from Fedora 33 (bash 5.0.17(1)-release) to 34 (bash 5.1.0(1)-release) the shell behaves odd. When pasting to shell, the pasted text is automatically marked, as if selected and it breaks earlier behavior.
I found a solution. Add the line "set enable-bracketed-paste off" in ~/.inputrc
>
> After upgrading from Fedora 33 (bash 5.0.17(1)-release) to 34 (bash 5.1.0(1)-release) the shell behaves odd. When pasting to shell, the pasted text is automatically marked, as if selected and it breaks earlier behavior.
GODSWILL DUKE
Feb 15, 2023, 1:26:05 PM2/15/23
to
0 new messages