Re: Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior

2025-03-17 Thread Martin D Kealey
It's important that sections of ~/.bashrc be ordered correctly to prevent
such issues. Just because someone tells you to add something to the *end*
of your .bashrc does not mean that's necessarily the best place to put it.

1) some boilerplate, including checking whether the shell is actually
interactive bash, plus:
  trap '' SIGINT SIGQUIT  # ignore ctrl-C and ctrl-\

2) any essential initialization - including variables like HISTFILE,
HISTFILESIZE, HISTSIZE, TERM, TRUECOLOR, TZ and shopt/set options.

3) optionally (useful if the remainder of the file might be "slow"):
  trap 'exit $?' SIGINT SIGQUIT  # abort login on ctrl-C and ctrl-\

4) read/include (“.”) files:
  - recommended by your OS
  - mandated by your system administrator
  - for any frameworks you want to use (ble, zcomp
  - containing your own customisations
(Grouping like this is useful, but some re-ordering may be required to
accommodate interdependencies.)

5) finish with:
  trap - SIGINT SIGQUIT  # normal handling for ctrl-C and ctrl-\

-Martin

PS: my own preferred approach is to set
HISTFILE=$HOME/.bash_history.d/$EPOCHSECONDS.$$ so that (a) bashrc can't
erase old history, and (b) history from different sessions isn't
interleaved. To recover old history, I use something like:
 while read histfile ; do history -r "$histfile" ; done < <( find
~/.bash_history.d/* -mtime -14 -print )
which relies on the `*` glob to sort the histfiles into time order. (I
leave it to my heirs to revise this before 20 November 2286.)

On Tue, 18 Mar 2025 at 05:26, Ionut Nicula  wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall
> uname output: Linux zinc 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.1.129-1 (2025-03-06) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.2
> Patch Level: 15
> Release Status: release
>
> Description:
> Had this weird issue on my work laptop where my .bash_history file
> would get truncated from time to
> time, and I had no idea what caused it because no background or
> foreground process should modify
> .bash_history in that way.
>
> Turns out that this was caused by pressing Ctrl+C when ~/.bashrc
> was being evaluated.
>
> Normally, on my PC, ~/.bashrc is very lightweight and I have a
> very very small window when I can
> press Ctrl+C and have it aborted. But at work, the init takes
> longer (~1 second) and I sometimes
> press Ctrl+C to abort it, run a command that doesn't depend on the
> .bashrc init, and then close
> the shell. But this effectively sets the history length to 500
> (the system default, instead of
> my actual infinite length in ~/.bashrc). When this happened
> before, I didn't notice it right
> away. I only noticed like a couple of hours after I accidentally
> truncated my bash history file,
> so I was very confused. It happened like 8 times in the last 12
> months and it happened again
> today, so I decided to spend a bit of time on it and find the issue.
>
> Repeat-By:
> 1. Write a ~/.bashrc file that sets the history length to allow
> infinite number of entries.
> 2. Write a global bash config that sets the history length limit to
> 500.
> 3. Add 1000 lines to the bash history file.
> 4. Add a command like 'sleep 999' to your ~/.bashrc before the
> lines that set up the infinite
>history size, in order to simulate a slow initialization.
> 5. Start a new bash instance, press Ctrl+C, and notice how
> .bash_history gets truncated to 500
>lines.
>
> Fix:
> I'm not sure what tweaks are 'allowed' here, but ideally, I would
> like some kind of flag that
> simply closes the bash instance if I ever press Ctrl+C during
> .bashrc evaluation because, as my
> report demonstrates, it can quite easily lead to weird and
> confusing behavior. I'm not sure if
> my suggested 'fix' is allowed (or makes sense) to be the default
> behavior.
>
>


Re: Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior

2025-03-17 Thread Chet Ramey

On 3/17/25 3:26 PM, Ionut Nicula wrote:


Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:
 Had this weird issue on my work laptop where my .bash_history file
would get truncated from time to
 time, and I had no idea what caused it because no background or
foreground process should modify
 .bash_history in that way.

 Turns out that this was caused by pressing Ctrl+C when ~/.bashrc
was being evaluated.

 Normally, on my PC, ~/.bashrc is very lightweight and I have a
very very small window when I can
 press Ctrl+C and have it aborted. But at work, the init takes
longer (~1 second) and I sometimes
 press Ctrl+C to abort it, run a command that doesn't depend on the
.bashrc init, and then close
 the shell. But this effectively sets the history length to 500
(the system default, instead of
 my actual infinite length in ~/.bashrc). When this happened
before, I didn't notice it right
 away. I only noticed like a couple of hours after I accidentally
truncated my bash history file,
 so I was very confused. It happened like 8 times in the last 12
months and it happened again
 today, so I decided to spend a bit of time on it and find the issue.

Repeat-By:
 1. Write a ~/.bashrc file that sets the history length to allow
infinite number of entries.
 2. Write a global bash config that sets the history length limit to 500.
 3. Add 1000 lines to the bash history file.
 4. Add a command like 'sleep 999' to your ~/.bashrc before the
lines that set up the infinite
history size, in order to simulate a slow initialization.
 5. Start a new bash instance, press Ctrl+C, and notice how
.bash_history gets truncated to 500
lines.


It's fairly straightforward: if you interrupt startup file execution before
setting important variables, those variables aren't set and, in some cases,
receive default values.



Fix:
 I'm not sure what tweaks are 'allowed' here, but ideally, I would
like some kind of flag that
 simply closes the bash instance if I ever press Ctrl+C during
.bashrc evaluation because, as my
 report demonstrates, it can quite easily lead to weird and
confusing behavior. 


If you want this, set a trap on SIGINT in your .bashrc that exits the
shell. You can reset the trap to the default as the last command in
your .bashrc.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Heredoc with a multiline delimiter

2025-03-17 Thread Chet Ramey

On 3/15/25 7:08 PM, MacBeth wrote:

On Sat, Mar 15, 2025 at 12:33 PM Greg Wooledge  wrote:

On Sat, Mar 15, 2025 at 16:14:00 +, Nikola Novak via Bug reports for the 
GNU Bourne Again SHell wrote:

How do you end the heredoc with a multiline delimiter such as the following:

cat << "a
b"


You don't.



However you could fake it, by including backslashes in the delimiter,
which would allow literal newlines,


It would not; this is a line continuation.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Heredoc with a multiline delimiter

2025-03-17 Thread Chet Ramey

On 3/15/25 9:18 PM, Robert Elz wrote:


POSIX says:

It is unspecified whether the line containing the trailing delimiter
is itself subject to this line continuation.

which means that nothing is required to make that work.   Further, unless
bash documents it as working, it is free to change the way it works for
that at any time, so was anyone to take your advice and actually use that
method, then they'd be risking their code breaking in a subsequent release,
with perhaps no warning at all.


The current version of the man page says:

"If the delimiter is not quoted, the \ sequence is treated as a
 line  continuation:  the two lines are joined and the backslash-newline
 is removed.  This happens while reading the here-document,  before  the
 check for the ending delimiter, so joined lines can form the end delim-
 iter."

I added it last September.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature


Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior

2025-03-17 Thread Ionut Nicula
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux zinc 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.129-1 (2025-03-06) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:
Had this weird issue on my work laptop where my .bash_history file
would get truncated from time to
time, and I had no idea what caused it because no background or
foreground process should modify
.bash_history in that way.

Turns out that this was caused by pressing Ctrl+C when ~/.bashrc
was being evaluated.

Normally, on my PC, ~/.bashrc is very lightweight and I have a
very very small window when I can
press Ctrl+C and have it aborted. But at work, the init takes
longer (~1 second) and I sometimes
press Ctrl+C to abort it, run a command that doesn't depend on the
.bashrc init, and then close
the shell. But this effectively sets the history length to 500
(the system default, instead of
my actual infinite length in ~/.bashrc). When this happened
before, I didn't notice it right
away. I only noticed like a couple of hours after I accidentally
truncated my bash history file,
so I was very confused. It happened like 8 times in the last 12
months and it happened again
today, so I decided to spend a bit of time on it and find the issue.

Repeat-By:
1. Write a ~/.bashrc file that sets the history length to allow
infinite number of entries.
2. Write a global bash config that sets the history length limit to 500.
3. Add 1000 lines to the bash history file.
4. Add a command like 'sleep 999' to your ~/.bashrc before the
lines that set up the infinite
   history size, in order to simulate a slow initialization.
5. Start a new bash instance, press Ctrl+C, and notice how
.bash_history gets truncated to 500
   lines.

Fix:
I'm not sure what tweaks are 'allowed' here, but ideally, I would
like some kind of flag that
simply closes the bash instance if I ever press Ctrl+C during
.bashrc evaluation because, as my
report demonstrates, it can quite easily lead to weird and
confusing behavior. I'm not sure if
my suggested 'fix' is allowed (or makes sense) to be the default behavior.