Re: Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior
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
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
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
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
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.