Enabling History Expansion with `set -H'.

[Ralph Corderoy]

Hi,

Please keep me CC'd.

bash package 4.4.012-2 on Arch Linux,
`version 4.4.12(1)-release (x86_64-unknown-linux-gnu)'.

I'm trying to enable history expansion in a non-interactive bash with
`set -H'.

$ printf '%s\n' ': foo' 'echo !!' 'set -H' ': bar' 'echo !!' |
> bash 
!!
!!
$

I'd expect the second `!!' to be `: bar'.
What am I misunderstanding?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

Re: Enabling History Expansion with `set -H'.

[Clint Hepner]

> On 2018 Jan 21 , at 7:13 a, Ralph Corderoy  wrote:
> 
> Hi,
> 
> Please keep me CC'd.
> 
> bash package 4.4.012-2 on Arch Linux,
> `version 4.4.12(1)-release (x86_64-unknown-linux-gnu)'.
> 
> I'm trying to enable history expansion in a non-interactive bash with
> `set -H'.
> 
>$ printf '%s\n' ': foo' 'echo !!' 'set -H' ': bar' 'echo !!' |
>> bash 
>!!
>!!
>$
> 
> I'd expect the second `!!' to be `: bar'.
> What am I misunderstanding?

You enabled history *expansion*, but not the history mechanism itself, so there 
is nothing for !! to expand to. You need `set -o history` as well.

$ printf '%s\n' ': foo' 'echo !!' 'set -H -o history' ': bar' 'echo !!' | 
bash
!!
echo : bar
: bar

The second line, 'echo : bar', is the result of the expansion itself, prior to 
the resulting command actually being executed.

In a script, when you kill a process, you get a terminal style message...

[gazelle]

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' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall
uname output: Linux shell 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 48
Release Status: release

Description:
This is actually a list of 3 issues that I've been saving up for some 
time.
The first one (which is referenced in the Subject line above) is the 
most
vexing, but all 3 are interesting.

1) In a script, when you kill a process, you get a terminal style message
about the process being killed.  See below for further description.

2) "shopt -s nullglob" breaks filename tab completion.  I found that tab 
completion
no longer works after I do that "shopt" command.

3) Using Escape v to edit a command line in vi mode works, but leaves the
keyboard in a funny state.  Specifically, it leaves you at the next bash 
prompt, but
in "vi mode" - i.e, hitting k displays the previous line in the history rather 
than
entering a 'k'.  The user effect is that the keyboard appears to be "stuck" 
until you
hit ^C to reset things.


Repeat-By:
(First, do: ln -sv /bin/sleep MySleep)
This is the script to demonstrate problem #1 in my list:
#!/bin/bash
{
./MySleep 32767
} &
echo "BASH_VERSION = $BASH_VERSION"
sleep 3
killall -v MySleep
sleep 1

Here is a run of this script:

$ ./testBashBug 
BASH_VERSION = 4.3.48(1)-release
Killed MySleep(7000) with signal 15
./testBashBug: line 4:  7000 Terminated  ./MySleep 32767
$ 

My point is that the "Terminated" message is pretty pointless when the
kill is from within a script.  It may worry a user unnecessarily.

Note that the setup has to be as above - where you run a {} list in the 
background,
then kill a process running within that {} group.