On 2/15/2019 9:32 PM, Dennis Williamson wrote:
>
>
>
>
> It's likely that somewhere your BASH_ALIASES has been unset. See the
> manual section quoted here:
>
> |BASH_ALIASES|
>
> An associative array variable whose members correspond to the
> internal list of aliases as maintained
Above appears to have been introduced in
https://git.savannah.gnu.org/cgit/bash.git/diff/jobs.c?h=devel&id=ee88838cf9421e2e40a7b7969cdf78a0010b075c
P.S. a similar thing happens (not resolved by reverting the above) with:
set +m; $BASH --norc -i -c 'exec xxx'
where "xxx" is not a valid comman
On Fri, Feb 15, 2019, 10:46 PM L A Walsh
> I printed the various declares using:
>
> declare -p |& more
>
> One of the early entries is:
>
> declare -A BASH_ALIASES=()
>
> Yet if I type 'alias |& wc, I see 56 lines starting with alias.
>
> I _thought_ BASH_ALIASES was suppose to hold the aliases
>
I printed the various declares using:
declare -p |& more
One of the early entries is:
declare -A BASH_ALIASES=()
Yet if I type 'alias |& wc, I see 56 lines starting with alias.
I _thought_ BASH_ALIASES was suppose to hold the aliases
and for an "alias whence='type -a'", I should see somethin
Looks like the controlling process group isn't being reset correctly
after the "inner" bash exits:
$ trap 'echo "$(ps -o pid,tpgid -p $$)"' EXIT
$ echo $$
54581
$ set +m
$ $BASH --norc -i -c 'set +m; echo $$'
54583
$
exit
PID TPGID
54581 54583
When in an interactive shell with job control disabled, starting
another interactive shell, disabling job control, and then exiting,
causes the parent shell to exit after any key press.
bash-5.0$ set +m; $BASH --norc -i -c 'set +m'
bash-5.0$ [any key]
exit
This seems to work fine in bash 4.4 and
An `exec` that can't execute the supplied command seems to cause the
status of job control to become reset to the default state:
$ bash -O execfail -mc 'echo $-; exec xxx; echo $-'
hmBc
bash: line 0: exec: xxx: not found
hBc
$ set +m; echo $-
hiBHs
$ exec xxx
bash: exec: x
> There is a third option: turning posix mode on saves the old binding
> for TAB; turning it off restores it. That, combined with a check of
> whether or not the binding was still TAB:self-insert, should handle
> both cases.
Thank you for your reply. I am fine with the third option as far as
`loca
Hi,
thanks for a quick response. I makes sense now. Did not think about the
calls with =, my bad.
On Fri, Feb 15, 2019 at 8:26 AM Vlad Vladov wrote:
> Hi,
> I think bash is great and more people should use it. However, it has a bit
> more picky syntax than many other modern languages and shell s
On 2/10/19 7:53 PM, Koichi Murase wrote:
>
> There may be several choices to fix this.
>
> a. One is to introduce a new variable that memorizes whether the
> binding has been defined by users or not. Or, maybe there are other
> ways to manage the information. Then, only when the binding is n
On Fri, Feb 15, 2019 at 9:51 AM Chet Ramey wrote:
> On 2/15/19 10:26 AM, Vlad Vladov wrote:
> > Hi,
> > I think bash is great and more people should use it. However, it has a
> bit
> > more picky syntax than many other modern languages and shell scripts. For
> > example assigning a var requires h
On 2/15/19 9:26 AM, Vlad Vladov wrote:
> Hi,
> I think bash is great and more people should use it. However, it has a bit
> more picky syntax than many other modern languages and shell scripts. For
> example assigning a var requires having no spaces between = and var and
> assignment. I think this
On 2/15/19 10:26 AM, Vlad Vladov wrote:
> Hi,
> I think bash is great and more people should use it. However, it has a bit
> more picky syntax than many other modern languages and shell scripts. For
> example assigning a var requires having no spaces between = and var and
> assignment. I think this
Hi,
I think bash is great and more people should use it. However, it has a bit
more picky syntax than many other modern languages and shell scripts. For
example assigning a var requires having no spaces between = and var and
assignment. I think this kind of thing can be fixed while still maintainin
14 matches
Mail list logo
