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
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
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 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/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
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
> 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
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
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
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
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
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
>
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 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
14 matches
Mail list logo
