stty permanently undef "start"

Post by Greg Wooledge
You could -- but if you do so, you should definitely surround it with
a check for stdin being a terminal (test -t 0 or equivalent).

Does bash execute .bashrc when it is not interactive?

Does bash think it is interactive when its input is not a tty?

Regards,

--
Nicolas George

Nicolas George

2024-07-10 14:30:01 UTC

Someone might source .bashrc from a binary in order to
access functions that are defined within it.

That would be shooting oneself in the foot. No need to cater for them.

Regards,

--
Nicolas George

Greg Wooledge

2024-07-10 14:50:01 UTC

Someone might source .bashrc from a binary in order to
access functions that are defined within it.

That would be shooting oneself in the foot. No need to cater for them.

There are many legitimate or semi-legitimate situations where a .bashrc
file might be read by a shell that's not running inside a terminal.

One of them is if someone chooses to dot in ~/.profile from their
~/.xsession file, or something analogous to it. Or perhaps their
operating system does this automatically in certain kinds of login.

Another might be a scripted ssh session being run from cron, or some
other parent that's not in a terminal. Analogously, the ancient
predecessors of ssh (rsh, rexec) had exactly the same issues.

When adding new commands to your shell dot files, always wrap commands
that assume/require the presence of a terminal in a check for a terminal.
You'll save yourself a *lot* of headaches.

Nicolas George

2024-07-10 15:00:01 UTC

Post by Greg Wooledge
There are many legitimate or semi-legitimate situations where a .bashrc
file might be read by a shell that's not running inside a terminal.
One of them is if someone chooses to dot in ~/.profile from their
~/.xsession file, or something analogous to it. Or perhaps their
operating system does this automatically in certain kinds of login.
Another might be a scripted ssh session being run from cron, or some
other parent that's not in a terminal. Analogously, the ancient
predecessors of ssh (rsh, rexec) had exactly the same issues.

What you describe is not legitimate, even semi-, these are hacks by
people who cannot be bothered to organize their configuration properly.

Post by Greg Wooledge
When adding new commands to your shell dot files, always wrap commands
that assume/require the presence of a terminal in a check for a terminal.
You'll save yourself a *lot* of headaches.

I save myself a lot of headaches by proper places for each snippet of
configuration. Which I can do because I use zsh instead of bash. zshrc
for interactive shell, zshenv for all shells, zprofile for interactive
login shells, etc.

We should not encourage people to pile hacks upon hacks.

Regards,

--
Nicolas George

Greg Wooledge

2024-07-10 15:10:01 UTC

What you describe is not legitimate, even semi-, these are hacks by
people who cannot be bothered to organize their configuration properly.

hobbit:~$ echo 'echo I AM BASHRC' >> .bashrc
hobbit:~$ ssh localhost date
***@localhost's password:
I AM BASHRC
Wed Jul 10 11:01:00 EDT 2024
hobbit:~$

Debian is, by your definition, a hack made by people who cannot be
bothered to organize their configuration properly.

Good to know.

(I won't even bother explaining because you CLEARLY know better than I
do about all topics. Enjoy your day.)

Nicolas George

2024-07-10 15:10:02 UTC

Post by Greg Wooledge
hobbit:~$ echo 'echo I AM BASHRC' >> .bashrc
hobbit:~$ ssh localhost date
I AM BASHRC
Wed Jul 10 11:01:00 EDT 2024
hobbit:~$

~ $ echo "I am in zshrc" >> .zshrc
~ $ ssh localhost date
~ $ ssh localhost date
Wed Jul 10 17:05:01 CEST 2024

Post by Greg Wooledge
Debian is, by your definition, a hack made by people who cannot be
bothered to organize their configuration properly.
Good to know.

Indeed. Anything that uses bash is, because bash lacks one config file
to make it possible to organize its configuration in a way that always
work. Hence, when using bash, hacks upon hacks to work around that core
issue.

Post by Greg Wooledge
(I won't even bother explaining because you CLEARLY know better than I
do about all topics. Enjoy your day.)

The risk of passive-aggressive like that is that you risk to be right.

Regards,

--
Nicolas George

t***@tuxteam.de

2024-07-10 16:00:01 UTC

[...]

Post by Greg Wooledge
(I won't even bother explaining because you CLEARLY know better than I
do about all topics. Enjoy your day.)

The risk of passive-aggressive like that is that you risk to be right.

Folks, let it be. You're both smart, you're both (kinda) right. and you
are both typically pretty helpful around here.

Enjoy life :-)

Cheers

--
t

Greg Wooledge

2024-07-10 17:40:01 UTC

To summarize:

* When configuring your shell dot files, make sure you DON'T write
anything to stdout, unless you have verified that stdout is a
terminal. Otherwise, it can mess up ssh sessions and other things.

* Likewise, DON'T run stty, or other terminal manipulation commands,
unless you've verified that stdin is a terminal. Otherwise, it
can cause errors, which may have unpredictable results in some
situations.

* If you feel that this doesn't apply to you, fine.

* For the rest of us, Debian has compiled its bash package with the
option that causes it to read .bashrc when run under sshd, even
when a command is given.

* Also, some operating systems, such as SuSE, have historically
configured their shells to read EVERY dot file regardless of
invocation mode. So, thinking "but it shouldn't read .bashrc because
I'm doing X, Y, or Z" may not necessarily be correct on such systems.

* Also, some operating systems read your shell dot files during an X
session startup, during which there is no terminal.

songbird

2024-07-10 23:10:01 UTC

What you describe is not legitimate, even semi-, these are hacks by
people who cannot be bothered to organize their configuration properly.

i see no problem with that at all.

but for my own purposes i also like to do things for
terminals when they open up (my session manager and the
overall desktop will store multiple desktops and all of
the terminals i have open in each of them when i ask it
to).

then in my .bashrc file i check to see what directory
the terminal opens in and create aliases and other things
for the specific project that i've got in that directory.
it's very nice to have just the aliases and environment
variables and other commands all set up and ready to go.

it's not a hack, it's a way of being efficient and
working the way that suits me. it also helps eliminate
some problems because i can also set my various PATH
environment variables to just what is needed and not
any thing more.

...

songbird

Nicolas George

2024-07-11 08:20:01 UTC

Post by songbird
but for my own purposes i also like to do things for
terminals when they open up (my session manager and the
overall desktop will store multiple desktops and all of
the terminals i have open in each of them when i ask it
to).

This is absolutely legitimate.

Note that tings in .bashrc will not affect terminals that run directly
another program, like “xterm -e vim”.

Post by songbird
then in my .bashrc file i check to see what directory
the terminal opens in and create aliases and other things
for the specific project that i've got in that directory.
it's very nice to have just the aliases and environment
variables and other commands all set up and ready to go.

This too is absolutely fine. I have even seen done this in pre-prompt
functions to have it exec when changing directory in the same shell.

Post by songbird
it's not a hack

This is not the hack. The hack comes when (1) you put things to
initialize the extended environment in .bashrc, (2) you source .bashrc
when it is not sourced.

All because this idiot bash does not have a .bashenv.

Regards,

--
Nicolas George

Franco Martelli

2024-07-10 15:40:01 UTC

Post by Greg Wooledge
test -t 0 && stty -ixon
That should be safe to add to your .bashrc.

...

Post by Greg Wooledge
One of them is if someone chooses to dot in ~/.profile from their
~/.xsession file, or something analogous to it. Or perhaps their
operating system does this automatically in certain kinds of login.

I changed my mind and I pasted the above command into ~/.profile thanks
it worked, now "rtorrent" quit properly by pressing the Ctrl-Q
combination. Despite "start" it's not set as "undef":

~$ stty -a
speed 38400 baud; rows 28; columns 110; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2
= M-^?; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon
ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke -flusho -extproc

The system is a headless RaspberryPI always up (Debian 11.7) that I use
as DHCP/BIND9/CUPS/SSH server. I run "rtorrent" inside a "screen" session:

~$ screen -S Torrent -d -m /usr/bin/rtorrent

All looks fine now.
Cheers

--
Franco Martelli

David Wright

2024-07-10 14:30:01 UTC

Post by Greg Wooledge
You could -- but if you do so, you should definitely surround it with
a check for stdin being a terminal (test -t 0 or equivalent).

Does bash execute .bashrc when it is not interactive?

Someone might source .bashrc from a binary in order to
access functions that are defined within it.

Post by Nicolas George
Does bash think it is interactive when its input is not a tty?

That would then be irrelevant.

Cheers,
David.

Vincent Lefevre

2024-07-26 22:20:01 UTC

Post by Greg Wooledge
You could -- but if you do so, you should definitely surround it with
a check for stdin being a terminal (test -t 0 or equivalent).

Does bash execute .bashrc when it is not interactive?

Yes, it may execute it. From the bash(1) man page:

If bash determines it is being run non-interactively in this
fashion, it reads and executes commands from /etc/bash.bashrc
and ~/.bashrc, if these files exist and are readable.

--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Dan Ritter

2024-07-10 14:50:01 UTC

Hi everybody,
I sometime use "rtorrent" (apt show rtorrent) to download isos and other big
files. It happens that when I had to quit rtorrent by press Ctrl-Q I cannot
because the key combination Ctrl-Q is trapped by the console due to "stty"

A glance at the wiki suggests that ctrl-Q just calls
"system.shutdown.normal"

So binding any other key to that command would be useful for
you.

Unfortunately, issue #817 says:

"You can override/set key-bindings with rtorrent-ps, although
you have to build your own ;) or get a precompiled build if
you're lucky."

Otherwise it would be ctrl-x, then system.shutdown.normal.

-dsr-

songbird

2024-07-10 23:00:01 UTC

Hi everybody,
I sometime use "rtorrent" (apt show rtorrent) to download isos and other
big files. It happens that when I had to quit rtorrent by press Ctrl-Q I
cannot because the key combination Ctrl-Q is trapped by the console due

that is a strange choice of termination and i would
actually consider it a bug in rtorrent, ESC or Ctrl-C
should work for that purpose.

...

songbird

Greg Wooledge

2024-07-10 23:00:02 UTC

Post by songbird

Hi everybody,
I sometime use "rtorrent" (apt show rtorrent) to download isos and other
big files. It happens that when I had to quit rtorrent by press Ctrl-Q I
cannot because the key combination Ctrl-Q is trapped by the console due

that is a strange choice of termination and i would
actually consider it a bug in rtorrent, ESC or Ctrl-C
should work for that purpose.

Emacs and bash both use Ctrl-S to do stuff, and in both cases, you need
to reconfigure your (virtual) terminal via stty(1) or equivalent to
disable XOFF/XON flow control before it'll work.

I'm sure these aren't the only three terminal programs that use ^S and/or
^Q as key bindings, under the assumption that you can press those keys
without triggering flow control. They're the only ones I'm currently
aware of, but I'd be shocked if there aren't more.

Sadly, the days of designing software to accomodate actual hardware
terminals are quite far behind us.

e***@gmx.us

2024-07-11 01:10:01 UTC

Post by songbird
that is a strange choice of termination and i would
actually consider it a bug in rtorrent, ESC or Ctrl-C
should work for that purpose.

Emacs and bash both use Ctrl-S to do stuff, and in both cases, you need
to reconfigure your (virtual) terminal via stty(1) or equivalent to
disable XOFF/XON flow control before it'll work.
I'm sure these aren't the only three terminal programs that use ^S and/or
^Q as key bindings, under the assumption that you can press those keys
without triggering flow control. They're the only ones I'm currently
aware of, but I'd be shocked if there aren't more.

^Q also quits LibreOffice apps, Thunderbird, Firefox, Pluma, and GIMP.

--
"God does not play dice" -- Einstein
"Not only does God play dice, he sometimes throws
them where they can't be seen." -- Stephen Hawking

Greg Wooledge

2024-07-11 01:20:01 UTC

Post by e***@gmx.us

Post by songbird
that is a strange choice of termination and i would
actually consider it a bug in rtorrent, ESC or Ctrl-C
should work for that purpose.

Emacs and bash both use Ctrl-S to do stuff, and in both cases, you need
to reconfigure your (virtual) terminal via stty(1) or equivalent to
disable XOFF/XON flow control before it'll work.
I'm sure these aren't the only three terminal programs that use ^S and/or
^Q as key bindings, under the assumption that you can press those keys
without triggering flow control. They're the only ones I'm currently
aware of, but I'd be shocked if there aren't more.

^Q also quits LibreOffice apps, Thunderbird, Firefox, Pluma, and GIMP.

Those are all X11 clients, though, yes? It's a completely different
story compared to terminal programs.

e***@gmx.us

2024-07-11 01:50:01 UTC

Post by e***@gmx.us

Post by songbird
that is a strange choice of termination and i would
actually consider it a bug in rtorrent, ESC or Ctrl-C
should work for that purpose.

Emacs and bash both use Ctrl-S to do stuff, and in both cases, you need
to reconfigure your (virtual) terminal via stty(1) or equivalent to
disable XOFF/XON flow control before it'll work.
I'm sure these aren't the only three terminal programs that use ^S and/or
^Q as key bindings, under the assumption that you can press those keys
without triggering flow control. They're the only ones I'm currently
aware of, but I'd be shocked if there aren't more.

^Q also quits LibreOffice apps, Thunderbird, Firefox, Pluma, and GIMP.

Those are all X11 clients, though, yes? It's a completely different
story compared to terminal programs.

Ah yes, it'd be a weird choice for a terminal app.

--
LEO: Now is not a good time to photocopy your butt and staple it
to your boss' face, oh no. Eat a bucket of tuna-flavored pudding
and wash it down with a gallon of strawberry Quik. -- Weird Al

songbird

2024-07-11 05:00:01 UTC

Greg Wooledge wrote:
...

Post by Greg Wooledge
Sadly, the days of designing software to accomodate actual hardware
terminals are quite far behind us.

true.

having been annoyed by the quit keys of Firefox i just
went and found the way to turn that off. been burned by
that one too many times and i'd still not looked into it
but i hope now that at least i've gotten that one nixed.

songbird

Max Nikulin

2024-07-11 15:50:01 UTC

Post by Greg Wooledge
test -t 0 && stty -ixon

I have a question opposite to the original one. Is it possible to
disable xon&xoff for bash prompt, but enable it while foreground
commands are running? Sometimes I use [Ctrl+s] to pause verbose output
of some tool. On the other hand I do not mind to use forward search in
readline history.

I have in mind a wrapper scripts that disables ixon while applications
like rtorrent are running. For emacs it should be some elisp code since
ixon should be active for "emacs -batch".

Can xon/xoff be managed from terminal application menu rather than from
inside of the terminal? It may be alternative to shell-specific feature.

Greg Wooledge

2024-07-11 16:00:02 UTC

Post by Greg Wooledge
test -t 0 && stty -ixon

In theory... you could run "stty -ixon" in the PROMPT_COMMAND variable,
and "stty ixon" in a DEBUG trap.

The DEBUG trap is run before each command, and the PROMPT_COMMAND
commands are run before displaying the prompt. So, it *should* work,
as long as you're aware that commands might change the terminal modes
themselves, and you aren't using DEBUG for anything else that would
interfere.

Max Nikulin

2024-07-12 04:00:01 UTC

Post by Greg Wooledge
test -t 0 && stty -ixon

In theory... you could run "stty -ixon" in the PROMPT_COMMAND variable,
and "stty ixon" in a DEBUG trap.

It seems PS0='$(stty ixon 2>/dev/null)' might be a better variant. I
have not tested it thoroughly yet.

I just have realized that enabling semantic terminal-shell integration
in konsole merely injects

if [[ ! $PS1 =~ 133 ]] ; then

PS1='\[\e]133;L\a\]\[\e]133;D;$?\]\[\e]133;A\a\]'$PS1'\[\e]133;B\a\]' ;
PS2='\[\e]133;A\a\]'$PS2'\[\e]133;B\a\]' ;
PS0='\[\e]133;C\a\]' ; fi

and it allows to mark prompt, command, and output.

https://per.bothner.com/blog/2019/shell-integration-proposal/
https://docs.kde.org/stable5/en/konsole/konsole/semantic-shell-integration.html

Max Nikulin

2024-07-19 11:50:01 UTC