Enhancement Request: Provide something like Emacs comint-get-next-from-history in Bash
Hi. To re-do previous command sequences from the history Bash provides operate-and-get-next (bound to C-o). So to re-do a sequence A B C of commands I need to navigate to A in the history and then enter A C-o (=> B) C-o (=> C) RET However, that requires the decision to re-do a sequence (and not only a single command) *BEFORE* the first command of the sequence is re-done. However, to me it happens quite frequently that I navigate to A, hit RET as usual and only then remember that I would have better hit C-o instead of RET. Emacs' function comint-get-next-from-history (bound to C-c C-x) uses a different approach: Here you navigate to A, press RET as usal, and press C-c C-x to get B and later C: A RET C-c C-x (=> B) RET C-c C-x (=> C) RET While these are more keystrokes, I find it more intuitive and flexible since I can decide *AFTER* having issued command A how to go on. I'm not sure whether something like that would be technically possible in Bash. I'd definitely like something like that. Thanks and regards Jens
Fix for #107950, Debian BTS #516152, #343673 and Ubuntu LP: #589496
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -D$ uname output: Linux desktop 2.6.35-32-generic #64-Ubuntu SMP Tue Jan 3 00:47:07 UTC 2012 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: Debian's bash (compiled with -DSYS_BASHRC) documentation says "--rcfile file: Execute commands from file instead of the system wide initialization file /etc/bash.bashrc and the standard personal initialization file ~/.bashrc if the shell is interactive." But testing shows that /etc/bash.bashrc is being executed even when --rcfile is used. So the only way for the user to disable the system-wide rc is to use the --norc option, which also disables both ~/.bashrc and any custom rc specified in --rcfile User should be able to prevent system rc and selecting a custom rc by using the --rcfile option, as per the documentation. Repeat-By: from any terminal: $ sudo echo "echo systemrc" > /etc/bash.bashrc $ echo "echo customrc" > ~/customrc $ echo "echo bashrc" > ~/.bashrc $ bash systemrc bashrc $ bash --rcfile ~/customrc --norc $ Current behavior: $ bash --rcfile ~/customrc systemrc customrc $ Expected behavior: $ bash --rcfile ~/customrc customrc $ Fix: To fix the behavior so it matches the documentation, SYS_BASHRC should only be executed if --rcfile is NOT used. Also, documentation should be updated to clarify that --norc option disables --rcfile option. Last but not least, -DSYS_BASHRC compile option should be properly documented, or at least included in configure options (as in --enable-system-bashrc) The attached files are: -xxx.patch: enables SYS_BASHRC so bug can be reproduced and the fix can be tested 0001-xxx.patch: Fixes the bug. This is the ONLY patch meant for merge. They were succesfully tested on git "master" branch (4.2 patchlevel 20) Sincerely, Rodrigo Silva (MestreLion in Launchpad) -SYS_BASHRC-enabled-in-config-top.h.patch Description: Binary data 0001-SYS_BASHRC-do-not-execute-etc-bash.bashrc-if-rcfile-is-set.patch Description: Binary data
set -e, bad substitutions, and trap EXIT
Hi,
Is this a bug? In the script below, I'm using a variable to control whether
the script uses set -e or not, because the behavior is dependent on whether set
-e is set. When the script hits the bad substitution, it runs the exit handler
and then exits as expected. However, with set -e, the exit status for the
script as a whole is wrong - it exits with 0 even though the script is
aborting. That's completely the opposite of what I'd expect. Without set -e
in force, it all works as expected.
I noticed also that when set -e is in force, the exit handler runs in a
different subshell when compared with the other case -- the prefix is "++" vs
"+" in the debug output.
This behavior is independent of whether set -o posix is in force.
~ $ echo $BASH_VERSION
4.2.8(1)-release
~ $ cat ./test.sh
#!/bin/bash
set -x
[ $SET_E ] && set -e
trap echo EXIT
echo ${$NO_SUCH_VAR}# Bad substitution expected here
~ $ SET_E= ./test.sh ; echo $?
+ '[' ']'
+ trap echo EXIT
./test.sh: line 8: ${$NO_SUCH_VAR}: bad substitution
+ echo
1
~ $ SET_E=1 ./test.sh ; echo $?
+ '[' 1 ']'
+ set -e
+ trap echo EXIT
./test.sh: line 8: ${$NO_SUCH_VAR}: bad substitution
++ echo
0
Thanks,
Ewan.
Error for large input files >2GB
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux backup 3.0.4.hflor #2 SMP Fri Oct 7 17:10:20 CEST 2011 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: I use a fuse in the control list of the files that were backed up. This list contains inode, size, date and file name. From the position of 2GB in this list are the variables inode, size, dat1, dat2 filled filepath is no longer with the right values and about 50 lines later, the variables are completely empty. (testscript.sh) Repeat-By: create_large_file.sh Fix: split file in max 2GB testscript.sh Description: Bourne shell script create_large_file.sh Description: Bourne shell script
