Re: Sv: TAB completion bug
On 12/10/23 7:23 PM, Ole Tange wrote: *Fra:* Chet Ramey On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again SHell wrote: For the (admitedly weirdly named) dirs below TAB completion does not work correctly. Thanks for the report. Where did you encounter these directory names? Test purposes. Fair enough. -- ``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: [PATCH] asort: some bug fixes
On Sun, Mar 26, 2023 at 08:19:25AM +0200, Emanuele Torre wrote:
> -sa = xmalloc(n * sizeof(sort_element));
> +if (n)
> + sa = xmalloc (n * sizeof(sort_element));
> i = 0;
> for ( j = 0; j < hash->nbuckets; ++j ) {
> bucket = hash->bucket_array[j];
> @@ -91,7 +92,8 @@ sort_index(SHELL_VAR *dest, SHELL_VAR *source)
> else {
> array = array_cell(source);
> n = array_num_elements(array);
> -sa = xmalloc(n * sizeof(sort_element));
> +if (n)
> + sa = xmalloc (n * sizeof(sort_element));
Oops, those should be
sa = n ? xmalloc (n * sizeof(sort_element)) : NULL;
Re: 回复: Possible bug in bash
On 1/17/23 2:21 AM, anonymous4feedb...@outlook.com wrote: I am sorry I made a mistake in the first email. Bash printed foo= bar=v and all other shells printed foo=v bar=. It turns out I am using --posix to enable alias in bash, and that’s what makes the difference. Thanks for the update; I fixed that posix-mode issue yesterday. It's better to turn off the check-next-word flag when reserved words are not eligible for alias expansion, even though bash has behaved the other way for a very, very long time. -- ``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/
Re: Bash 5.1: Completion bug fix
On 4/13/21 3:44 PM, Marc Aurèle La France wrote: Fix a bug in attempt_shell_completion() since 4.3-beta that allows the programmable completion code to override a prior decision made by attempt_shell_completion() that command completion is >not< to be used. Thanks for the report and fix. Chet -- ``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/
Re: Probably not a bug but I was surprised: $' does not work inside "..." close.
Greg Wooledge writes: > $'...' is a form of quoting, not an expansion. It won't "work" inside > of another type of quoting, just like '...' will not "work" inside "...". Yes, that's true, and makes sense when I think about it. But the manual page doesn't consistently phrase it that way: Words of the form $'string' are treated specially. The word expands to string, ... As you say, it isn't "expand". And, being a quote construct, it's not a word per se, it prevents contained characters from breaking words. On the flip side, it doesn't look like there's a consistent word for "the effective value of a quote construct", although "quote removal" is used in some places. Dale
Re: Probably not a bug but I was surprised: $' does not work inside "..." close.
On Wed, Mar 17, 2021 at 09:11:48PM -0400, Dale R. Worley wrote: > I have it encoded in my head that $ inside "..." is respected. Subtly, > the $'...' construction is not respected inside "...". Bash has 5 types of quoting: '...', "...", $'...', $"..." and backslash. $'...' is a form of quoting, not an expansion. It won't "work" inside of another type of quoting, just like '...' will not "work" inside "...". echo "foo is '$foo'" In this example, $foo is expanded, despite the fact that there are single quotes around it, because the single quotes have no meaning in this context. They're inside a *different* type of quoting, so they are just regular literal characters. The only exception here is backslash, which retains its special powers when inside "..." or $"...".
Re: is it a bug that \e's dont get escaped in declare -p output
On 3/17/21 4:04 PM, Greg Wooledge wrote: On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote: On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote: I thought, for a moment, that bash already used $'...' quoting for newlines, but it turns out that's false. At least for declare -p. It would be nice if it did, though. Newlines, carriage returns, escape characters, etc. It does in some cases: $ a=($'new \n line' $'and \e esc'); declare -p a declare -a a=([0]=$'new \n line' [1]=$'and \E esc') But not for string variables, it seems. unicorn:~$ unset a b; a=($'x\ny') b=$'c\nd'; declare -p a b declare -a a=([0]=$'x\ny') declare -- b="c d" It would be nice if the string variables were handled the same way as the array elements. This is not unreasonable. -- ``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/
Re: is it a bug that \e's dont get escaped in declare -p output
Le 17/03/2021 à 21:13, Alex fxmbsw7 Ratchev écrivait :
hm at least now we know array declare -p formatting would work in
workarounds, good to .. :)
Instead of:
var=$'1\e[G\e[K2' ; declare -p var
do:
var=$'1\e[G\e[K2' ; printf 'declare -- %s\n' "${var@A}"
And if you want a human readable dumpvars, then code it.
Here it is:
#!/usr/bin/env bash
dump_vars () {
local ___varname
for ___varname; do
local ___varflags=${!___varname@a}
___varflags=${___varflags:--}
if [[ "$___varflags" =~ [Aa] ]]; then
declare -p "$___varname"
else
printf 'declare -%s %s=%q\n' "$___varflags" "$___varname"
"${!___varname}"
fi
done
}
escapestring=$'1\e[G\e[K2'
escapearray=($'new \n line' $'and \e esc')
declare -A assocarray=([$'1\e[G\e[K2']=$'and \e esc' [$'new \n
line']=$'1\e[G\e[K2')
declare -i intvar=42
declare -ai intarray=(-42 666 555)
declare -Ai intassoc=([foo]=123 [$'1\e[G\e[K2']=456 [bar]=789)
dump_vars escapestring escapearray assocarray intvar intarray intassoc
Output:
declare -- escapestring=$'1\E[G\E[K2'
declare -a escapearray=([0]=$'new \n line' [1]=$'and \E esc')
declare -A assocarray=([$'1\E[G\E[K2']=$'and \E esc' [$'new \n
line']=$'1\E[G\E[K2' )
declare -i intvar=42
declare -ai intarray=([0]="-42" [1]="666" [2]="555")
declare -Ai intassoc=([$'1\E[G\E[K2']="456" [foo]="123" [bar]="789" )
declare -i nameref=42
--
Léa Gris
OpenPGP_signature
Description: OpenPGP digital signature
Re: is it a bug that \e's dont get escaped in declare -p output
Le 17/03/2021 à 20:58, Ilkka Virta écrivait : On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote: I thought, for a moment, that bash already used $'...' quoting for newlines, but it turns out that's false. At least for declare -p. It would be nice if it did, though. Newlines, carriage returns, escape characters, etc. It does in some cases: $ a=($'new \n line' $'and \e esc'); declare -p a declare -a a=([0]=$'new \n line' [1]=$'and \E esc') I'd expect bash to escape any character not in the POSIX [:print:] class. Although this is just a question of QOL improvement, since the produced declare statement just works as-is. It is not user friendly but code friendly and compact if you use the declare -p foo bar baz >savedvars.sh for later include savedvars.sh -- Léa Gris OpenPGP_signature Description: OpenPGP digital signature
Re: is it a bug that \e's dont get escaped in declare -p output
hm at least now we know array declare -p formatting would work in workarounds, good to .. :) On Wed, Mar 17, 2021 at 9:05 PM Greg Wooledge wrote: > On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote: > > On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote: > > > > > I thought, for a moment, that bash already used $'...' quoting for > > > newlines, but it turns out that's false. At least for declare -p. > > > It would be nice if it did, though. Newlines, carriage returns, escape > > > characters, etc. > > > > > > > It does in some cases: > > > > $ a=($'new \n line' $'and \e esc'); declare -p a > > declare -a a=([0]=$'new \n line' [1]=$'and \E esc') > > But not for string variables, it seems. > > unicorn:~$ unset a b; a=($'x\ny') b=$'c\nd'; declare -p a b > declare -a a=([0]=$'x\ny') > declare -- b="c > d" > > It would be nice if the string variables were handled the same way as > the array elements. > >
Re: is it a bug that \e's dont get escaped in declare -p output
On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote: > On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote: > > > I thought, for a moment, that bash already used $'...' quoting for > > newlines, but it turns out that's false. At least for declare -p. > > It would be nice if it did, though. Newlines, carriage returns, escape > > characters, etc. > > > > It does in some cases: > > $ a=($'new \n line' $'and \e esc'); declare -p a > declare -a a=([0]=$'new \n line' [1]=$'and \E esc') But not for string variables, it seems. unicorn:~$ unset a b; a=($'x\ny') b=$'c\nd'; declare -p a b declare -a a=([0]=$'x\ny') declare -- b="c d" It would be nice if the string variables were handled the same way as the array elements.
Re: is it a bug that \e's dont get escaped in declare -p output
On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote: > I thought, for a moment, that bash already used $'...' quoting for > newlines, but it turns out that's false. At least for declare -p. > It would be nice if it did, though. Newlines, carriage returns, escape > characters, etc. > It does in some cases: $ a=($'new \n line' $'and \e esc'); declare -p a declare -a a=([0]=$'new \n line' [1]=$'and \E esc')
Re: is it a bug that \e's dont get escaped in declare -p output
On Wed, Mar 17, 2021 at 01:55:56PM -0400, Eli Schwartz wrote: > On 3/17/21 12:43 PM, Alex fxmbsw7 Ratchev wrote: > > it makes the output no more possible if interpreted by tty > > the \e's get processed by terminal and no more .. just an example where it > > is so: > > > > var=$'1\e[G\e[K2' ; declare -p var > > > > if G was H for other line then it completly messes the terminal up > > > > isnt it better to escape by \e ? .. > > Why is it the bash script interpreter's job to escape user-supplied > strings based on how a terminal emulator chooses to *visually* display > the results? Call it a request for enhancement. I thought, for a moment, that bash already used $'...' quoting for newlines, but it turns out that's false. At least for declare -p. It would be nice if it did, though. Newlines, carriage returns, escape characters, etc.
Re: is it a bug that \e's dont get escaped in declare -p output
On 3/17/21 12:43 PM, Alex fxmbsw7 Ratchev wrote: > it makes the output no more possible if interpreted by tty > the \e's get processed by terminal and no more .. just an example where it > is so: > > var=$'1\e[G\e[K2' ; declare -p var > > if G was H for other line then it completly messes the terminal up > > isnt it better to escape by \e ? .. Why is it the bash script interpreter's job to escape user-supplied strings based on how a terminal emulator chooses to *visually* display the results? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
Date:Wed, 17 Mar 2021 09:12:19 -0400 From:Chet Ramey Message-ID: | If you don't modify PWD, PWD always reflects the current working directory, Of course, but how is that relevant? But even that isn't actually specified, if one does a popd does PWD not change? The description of PWD (see just below) doesn't say it does. | If you modify PWD, as I said, all bets are off. Does the man page say (or even hint) at that somewhere? The only references I can find to PWD are in the list of variables set by bash, which says (in its entirety) PWDThe current working directory as set by the cd command. but the description of the cd command says nothing about it at all. (It does mention OLDPWD, but only in the context of specifying what "cd -" means). Aside from that definition, PWD is used to define the ~+ expansion, and as best I can tell, those are the only references to it anywhere in the doc. There is a list of variables: The following variables are used by the shell. but PWD is not in that list. PWD is in the list: Shell Variables The following variables are set by the shell: Some of those give details about what happens when they're modified, (eg: DIRSTACK) some are listed as read only, PWD is just as above. How do you expect a user to know that modifying PWD might cause bash to halt and catch fire ? I believe some work on the doc would be useful. kre
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
On 3/16/21 11:20 PM, Robert Elz wrote: | If you want to set PWD instead of letting cd/pushd/popd manage it, | all bets are off. I agree with that as far as what you get when you expand $PWD (even the pwd command, so using `pwd` as an alternative if PWD has been manually set is not necessarily going to work), and even the way the cd command works, but the bash man page says: \w the current working directory, with $HOME abbreviated with a tilde (uses the value of the PROMPT_DIRTRIM variable) Nothing about $PWD there, it should be the current working directory, If you don't modify PWD, PWD always reflects the current working directory, as it says in its description. If you modify PWD, as I said, all bets are off. -- ``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/
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
Date:Tue, 16 Mar 2021 09:31:24 -0400
From:Chet Ramey
Message-ID: <31aff163-9e61-d34a-be79-40c7e09a8...@case.edu>
| If you want to set PWD instead of letting cd/pushd/popd manage it,
| all bets are off.
I agree with that as far as what you get when you expand $PWD (even the
pwd command, so using `pwd` as an alternative if PWD has been manually
set is not necessarily going to work), and even the way the cd command
works, but the bash man page says:
\w the current working directory, with $HOME abbreviated
with a tilde (uses the value of the PROMPT_DIRTRIM
variable)
Nothing about $PWD there, it should be the current working directory,
according to that definition, and one thing that changing PWD does not
do is change the current working directory.
Of course, the simple fix to this is to change the man page, so refer
to $PWD instead of "the current working directory".
| Just like setting HOME changes tilde expansion.
It does, but that's not really an analogy, ~/ is defined to be ${HOME}/
so if changing HOME did not have that effect then ~ expansion would be
broken. If changing HOME had any effect on ~kre/ (given that the
relevant user name is used, such that it should produce what is normally
in an unaltered $HOME) however, then that would be a problem.
kre
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
okay, cool, thank you for valuable infos =)) On Tue, Mar 16, 2021 at 2:31 PM Chet Ramey wrote: > On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote: > > .. ? > > > > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == > > 2021-03-16+11:22:2920 ) # > > PWD=/bla > > No. If you want to set PWD instead of letting cd/pushd/popd manage it, > all bets are off. > > Just like setting HOME changes tilde expansion. > > > -- > ``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/ >
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote: .. ? # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == 2021-03-16+11:22:2920 ) # PWD=/bla No. If you want to set PWD instead of letting cd/pushd/popd manage it, all bets are off. Just like setting HOME changes tilde expansion. -- ``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/
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
but is it a bug its a bug to use heavy subshells for such i understand the addment of this case tho On Tue, Mar 16, 2021 at 1:23 PM Chris Elvidge wrote: > On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote: > > .. ? > > > > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == > > 2021-03-16+11:22:2920 ) # > > PWD=/bla > > # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == > > 2021-03-16+11:23:1920 ) # > > > > Yes, it seems \w (and \W) take their values from $PWD > If you want to register the current directory in $PS1 regardless, change > \w to `pwd` > > -- > Chris Elvidge > England > > >
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote: .. ? # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == 2021-03-16+11:22:2920 ) # PWD=/bla # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == 2021-03-16+11:23:1920 ) # Yes, it seems \w (and \W) take their values from $PWD If you want to register the current directory in $PS1 regardless, change \w to `pwd` -- Chris Elvidge England
Re: is it a bug
that ive written not nothing.. big thanks for your true efford, and thanks
for future bugfixing it, ..important issue
i also had the same with && after [[ somewhere with also fail
but since i switched to one command one line it all yet works, the bit that
im trying
thanks, peace
On Tue, Nov 17, 2020, 07:37 L A Walsh wrote:
> On 2020/11/16 11:02, Alex fxmbsw7 Ratchev wrote:
> > on my way for a new paste
> Anytime you start going over multiple lines in an alias, you
> need to consider the use of a function, where 'need' would ideally
> increase in proportion to the number of lines you are including.
>
> For increased readability, I took out 'aal' being prepended to
> every variable except the two usages of 'aal[...]' where I substituted
> 'foo' for 'aal'. NOTE: the code seems to use 'foo' (or 'aal') without it
> being initialized.
>
> The main oddity I found was that if (in my version),
> t=""
> is on the same line as 'res=()', I get the error with unexpected ';'
> since it doesn't seem to parse the 'for' statement's "for", so the
> semi after it is unexpected.
>
> For some strange reason, the parsing of the array doesn't break off
> at the space, in fact, when the lines are split, the alias seems
> to lose some spacing (note 'res=t='):
>
> executing alias +ax
> res=t=
> alias -- "t="
>
> This seemed to be the minimum difference between a working & non working
> case. Either (for no error):
> an_alias='res=()
> t=""
> for ci in "${!foo[@]}"; do \
>
> or (to reproduce error):
> an_alias='res=() t=""
> for ci in "${!foo[@]}"; do \
>
> error I got was:
> ./aldef.sh: array assign: line 23: syntax error near unexpected token `;'
> ./aldef.sh: array assign: line 23: `res=() t=""
>
> It is doing something weird -- I suspect that
> alias expansion is expanding the right side as 'text' and not
> as code that gets interpreted when the substitution occurs.
>
> Try reserving aliases where it is needed (something a function can't do)
> or where it helps legibility.
>
> Hope this helps...ohincluding the version that gives an error.
> To see version that works, split the 't=""' to be on the line
> below the 'res=()'.
>
> -linda
>
>
>
>
Re: is it a bug
On 11/17/20 7:56 AM, Greg Wooledge wrote:
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
or (to reproduce error):
an_alias='res=() t=""
for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
for i in 1; do echo hi; done'
unicorn:~$ foo
bash: syntax error near unexpected token `;'
unicorn:~$ alias bar='a=()
b=""
for i in 1; do echo hi; done'
unicorn:~$ bar
hi
Interesting. Thanks for the simple reproducer, both of you. I'll take a
look after bash-5.1 is out.
--
``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/
Re: is it a bug
$ alias x='a=() foo echo $a' $ x foo $ declare -p a declare -a a=([0]="foo") Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: is it a bug
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
> or (to reproduce error):
> an_alias='res=() t=""
>for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
> for i in 1; do echo hi; done'
unicorn:~$ foo
bash: syntax error near unexpected token `;'
unicorn:~$ alias bar='a=()
> b=""
> for i in 1; do echo hi; done'
unicorn:~$ bar
hi
Re: is it a bug
On 2020/11/16 11:02, Alex fxmbsw7 Ratchev wrote:
on my way for a new paste
Anytime you start going over multiple lines in an alias, you
need to consider the use of a function, where 'need' would ideally
increase in proportion to the number of lines you are including.
For increased readability, I took out 'aal' being prepended to
every variable except the two usages of 'aal[...]' where I substituted
'foo' for 'aal'. NOTE: the code seems to use 'foo' (or 'aal') without it
being initialized.
The main oddity I found was that if (in my version),
t=""
is on the same line as 'res=()', I get the error with unexpected ';'
since it doesn't seem to parse the 'for' statement's "for", so the
semi after it is unexpected.
For some strange reason, the parsing of the array doesn't break off
at the space, in fact, when the lines are split, the alias seems
to lose some spacing (note 'res=t='):
executing alias +ax
res=t=
alias -- "t="
This seemed to be the minimum difference between a working & non working
case. Either (for no error):
an_alias='res=()
t=""
for ci in "${!foo[@]}"; do \
or (to reproduce error):
an_alias='res=() t=""
for ci in "${!foo[@]}"; do \
error I got was:
./aldef.sh: array assign: line 23: syntax error near unexpected token `;'
./aldef.sh: array assign: line 23: `res=() t=""
It is doing something weird -- I suspect that
alias expansion is expanding the right side as 'text' and not
as code that gets interpreted when the substitution occurs.
Try reserving aliases where it is needed (something a function can't do)
or where it helps legibility.
Hope this helps...ohincluding the version that gives an error.
To see version that works, split the 't=""' to be on the line
below the 'res=()'.
-linda
aldef.sh
Description: Bourne shell script
Re: is it a bug
On Mon, Nov 16, 2020 at 9:38 PM Robert Elz wrote:
>
> Personally I'd go further and suggest that no-one should ever use aliases
> for anything, ever ...
>
I don't understand why people "hate" aliases so much. :) For me it's much
simpler/shorter than functions. And the "alias" command (without any
options) output is more compact than "declare -f". Just take a look at some
of my aliases (I have ~150 aliases in total):
alias B='builtin'
alias C='command'
alias D='date'
alias E='export'
alias F='find'
alias G='git'
alias H='history'
alias I='ifconfig'
alias K='killall'
alias L='less'
alias M='LC_ALL=C MANWIDTH=$(( COLUMNS > 120 ? 120 : COLUMNS )) man'
alias N='netstat'
alias O='openssl'
alias P='patch'
alias R='route'
alias T='touch'
alias U='uname'
alias V='echo $BASH_VERSION'
alias W='watch'
alias X='screen -X'
alias Z='reset'
alias a='alias'
alias b='builtin cd -'
alias c='clear'
alias d='diff'
alias e='echo'
alias f='file'
alias g='grep'
alias h='help'
alias i='command info'
alias j='jobs'
alias k='kill'
alias l='ls -l'
alias m='make'
alias n='mount'
alias p='patch'
alias q='exit'
alias r='fc -s'
alias s='screen'
alias t='type'
alias u='umount'
alias v='vim'
alias x='xargs'
alias z='echo "${COLUMNS}x$LINES ${TERM:+($TERM)}"'
Re: is it a bug
on my way for a new paste, i came over more such unexpected ';' token
errors, yet i seemed for workaround\compatibility to work around em by not
using ; at all, also on end of final done cause that error would appear
im still working on making my code acceptable
On Sat, Nov 14, 2020, 20:29 Alex fxmbsw7 Ratchev wrote:
> ( http://ix.io/2E6y )
> as.. the +al code worked and the +al alias was defined thru it.. just
> gives the shown ; error on use
>
>++ BEGINFILE ii.x7yz.1
>
> i code shortened coding codings, or at least wish to
> here in my x7yz control script i '. -- +al' a ./+al file which then sets
> aliases by file content, it does so
> but the resulting +al alias of itself says when usage syntax error ';'
> unexpected
> some other aliases work tho
>
> any ideas ?
>
>-- ENDFILE ii.x7yz.1 -=| 285 chars 55 words 6 lines
>++ BEGINFILE oo.x7yz.4
>
> root@boost:~/x7yz# . x7yz
> root@boost:~/x7yz# type +al
> +al is aliased to `aalres=( ) aalt=
> for caali in "${!aal[@]}" ; do
> aalres[caali]=$(
> printf %s "${aal[caali]}="
> if [[ -f ${aalt:=${aald[caali]:-${aal[caali]}}} ]] ; then
>exec cat -- "$aalt"
> else
>printf -- %s "$aalt"
> fi
> ) aalt=
> done
> [[ -v aalres[0] ]] &&
> alias -- "${aalres[@]}" ; '
> root@boost:~/x7yz# +al
> bash: syntax error near unexpected token `;'
> root@boost:~/x7yz#
>
>-- ENDFILE oo.x7yz.4 -=| 439 chars 63 words 18 lines
>++ BEGINFILE x7yz
>
> #!/bin/bash
> self=${BASH_SOURCE##/*} self=${self+$PWD/$self} self=${self:-$BASH_SOURCE} \
> dir=${self%/*} ; cd "$dir"
> shopt -s extglob globstar expand_aliases
> aal=( +al KWS +kw kwp )
> . -- "$aal"
> KWS
>
>
>-- ENDFILE x7yz -=| 198 chars 24 words 8 lines
>++ BEGINFILE +al
>
> aalres=( ) aalt=
> for caali in "${!aal[@]}" ; do
> aalres[caali]=$(
> printf %s "${aal[caali]}="
> if [[ -f ${aalt:=${aald[caali]:-${aal[caali]}}} ]] ; then
>exec cat -- "$aalt"
> else
>printf -- %s "$aalt"
> fi
> ) aalt=
> done
> [[ -v aalres[0] ]] &&
> alias -- "${aalres[@]}" ;
>
>-- ENDFILE +al -=| 278 chars 42 words 13 lines
>-- END of 4 pastes ( 1200 chars 184 words 45 lines
>
>
>
Re: is it a bug
Date:Mon, 16 Nov 2020 08:49:21 -0500 From:Greg Wooledge Message-ID: <20201116134921.gn...@eeg.ccf.org> | If a bug can actually be pinpointed and demonstrated, | I'm sure Chet would care. Chet might. I don't. I doubt many others do. | It's too convoluted. Just write a simple two- or | three-line demonstration of the problem. Agree that is better, but some bugs don't ever manifest under those conditions. I have had bugs (not in bash) that take pages of code to reproduce. I suspect this might be one like that. kre
Re: is it a bug
On Mon, Nov 16, 2020 at 08:37:05PM +0700, Robert Elz wrote: > Dale's point, with which I agree, is that you shouldn't even be attempting > using aliases for things like that. If there is some bug there, I don't > care, and I doubt anyone else does either. If a bug can actually be pinpointed and demonstrated, I'm sure Chet would care. My problem with this thread is that I can't make any sense of the original bug report at all. It's too convoluted. Just write a simple two- or three-line demonstration of the problem. Or better still, describe what the goal is. "I have some code in a file which defines aliases, and I want to use those in my script" -- well then, simply source that file.
Re: is it a bug
Date:Mon, 16 Nov 2020 13:52:55 +0100 From:Alex fxmbsw7 Ratchev Message-ID: | small conclusion: . code works, eval "$( < file )" worked, but alias | version not without empty newline Dale's point, with which I agree, is that you shouldn't even be attempting using aliases for things like that. If there is some bug there, I don't care, and I doubt anyone else does either. Personally I'd go further and suggest that no-one should ever use aliases for anything, ever ... aliases originated in csh (or perhaps ashell which preceded it) which had no functions, and lacked the syntactic ability to really add them - aliases were its mechanism to allow users to define new commands that affect the state of the shell itself. ksh apparently copied that (part of what csh allowed), but then created functions, which are a much better method to achieve the same goal - aliases should have been deleted when that happened. But weren't (it isn't as if ksh/bash (or POSIX) aliases are powerful enough to actually replace csh aliases in general, whereas functions are). The only use for aliases that can't be done with functions is to create new sh syntax (as some combination of existing syntax) which is a spectacularly bad idea, and should never be actually used by anyone, for anything, other than demonstrating just how crazy it really is. I generally stop reading bash example code as soon as it starts using arrays. As best I can guess is that you're writing an alias for defining aliases, if you just used a function instead (as Dale suggested) this would be much simpler and cleaner. But once you've done that, you should throw it away, as you shouldn't be using aliases at all, you really have no need for some shorthand method of making them. kre
Re: is it a bug
thank you sir dale, while i was cleaning up the code for another paste with more details i came across that when i add a empty newline before the first for, the bug line disappears small conclusion: . code works, eval "$( < file )" worked, but alias version not without empty newline .. im sorry i have a hard time typing on android stuff long On Mon, Nov 16, 2020, 05:18 Dale R. Worley wrote: > Alex fxmbsw7 Ratchev writes: > > i code shortened coding codings, or at least wish to > > here in my x7yz control script i '. -- +al' a ./+al file which then > > [...] > > any ideas ? > > This is *really* hard to understand. None of the names of files, > variables, or functions describes what they are intended to do, and > there are no comments that do so. It is likely that much of the code > could be removed and still have an illustration of the problem case. > > Also, it is generally recommended that aliases be replaced with > functions, as the processing of functions has better syntactic and > semantic behavior. > > Dale >
Re: is it a bug
Alex fxmbsw7 Ratchev writes: > i code shortened coding codings, or at least wish to > here in my x7yz control script i '. -- +al' a ./+al file which then > [...] > any ideas ? This is *really* hard to understand. None of the names of files, variables, or functions describes what they are intended to do, and there are no comments that do so. It is likely that much of the code could be removed and still have an illustration of the problem case. Also, it is generally recommended that aliases be replaced with functions, as the processing of functions has better syntactic and semantic behavior. Dale
Re: Is this a bug?
On 8/25/20 8:21 PM, George R Goffe wrote: > I could try running strace during all of this. Would it help? It might indicate the order in which things are happening. -- ``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/
Re: Is this a bug?
On 8/25/20 3:47 PM, George R Goffe wrote: > Chet, > > I appreciate your help with this. > > Do "we" know that bash IS trying to generate an alarm? Yes, we are fairly sure that bash is trying to `ring' the bell. When I run bind 'set bell-style audible' and type the common prefix of a set of filenames in the current directory, then hit TAB, bash rings the bell. -- ``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/
Re: Is this a bug?
I was going to suggest this analysis, but George has gotten ahead of me, so let me collate the two: My understanding is that the details of how different programs read directories differs, and how different operating systems implement those operations differs, and how different file systems under an operating system implement them differs. But overall, reading large directories can take a long time, and often the operations involved are not interruptable. (At root, that is because this is an uncommon scenario in Unix and people don't work to optimize it.) So I was going to recommend this calibration: Go to the directory in question and execute "time ls -1 >/dev/null". That gives you the maximum amount of time it will take to read that directory, and that should be an upper bound on how long it will take bash to finish whatever completion operation it is doing. George R Goffe writes: > I found how how to make konsole do a visual alarm and then tried my > failure scenario. > > I cd'd to a "big" directory and then entered "ls -al abc", > waited a few seconds then did a ctrl-c. As usual, a freeze happened. I > waited a while and then saw the visual alarm followed by the ctr-c. OK, so it looks like there is some long, uniterruptable operation happening as part of filename completion. How does the length of that freeze compare to "ls -1", as described above? > Somewhere between the request for filename completion and the > recognition of ctrl-c appears to be where the "bug" is located. > > I could try running strace during all of this. Would it help? My guess is that could reveal some particularly slow operating system call that is involved in implementing filename completion, but it would not indicate a way to improve it. Dale
Re: Is this a bug?
> On Aug 25, 2020, at 3:47 PM, George R Goffe wrote: > > I have gone searching for doc on how to set alarm behavior in > konsole. I found none. I have written a bug about his at the KDE > bug site. ARGH! They have been singularly unresponsive when it comes > to bug reports. We'll see. This suggests that Konsole does not support a typical visual bell, although I can't vouch for its accuracy or continued relevance (it's over three years old). https://unix.stackexchange.com/q/371019 vq
Re: Is this a bug?
On 8/24/20 4:15 PM, George R Goffe wrote: > Chet, > > I'm not seeing any visual "bells". The audio part of this computer is > broken... NO sound... I'm not sure what I can do about that. If the visual bell doesn't work and the sound is broken, you're not going to get much of an indication no matter what you do. Chet -- ``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/
Re: Is this a bug?
On 8/22/20 5:25 PM, George R Goffe wrote: > > Chet, > > I'm really perplexed with this situation. I type in "ls -al 123456" with > only 1 tab key. NO indication of what's happening. I hit enter and get a > message that "ls: cannot access '123456': No such file or directory" I try > the same command but with 2 tab keys... hit enter and get the same msg. Readline defaults to a visual bell, using the terminal's `vb' capability. You can set the readline `bell-style' variable to `audible' to change that. If you do, make sure your terminal emulator does something reasonable with the ^G character. > I tried the same with a partial filename that DOES exist in the directory. I > can't seem to get the filename completion to ctrl-c out. gdb sees the ctrl-c > but bash stays in the attempted filename completion. Enter doesn't work. > Ctrl-c doesn't work. Ctrl-z doesn't work. I just can't reproduce this. (Though there's no reason to expect ^Z to have any effect, since we're not running a separate job here.) > > Shouldn't there be a message about no file found presented by bash? There > appears to be NO indication that filename completion has failed to find a > file. Why would a message be appropriate here? It seems to me that the visible or audible bell is the right indicator. -- ``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/
Re: Is this a bug?
George R Goffe writes: > Shouldn't there be a message about no file found presented by bash? > There appears to be NO indication that filename completion has failed > to find a file. I'm not very experienced using filename completion, but my understanding is that completion indicates "there is no file with this prefix" by ringing the bell, and I assume that specifically means emitting a \007 character. bash depends on whatever "terminal program" it is running under to give the user an indication that \007 has been emitted. In the one system to hand, the terminal program is xterm, but it gives no indication for \007. And my memory is that over the years, support for "the bell" has been poor and inconsistent. Now maybe there's a way to configure bash to indicate no-completion-choices in a different way. > I'm at a loss as to what to do at this point. What I would like to be > able to ctrl-c out of filename completion. Sorry, I've re-read your messages and I can't tell what your situation really is. Can you describe a test case where you can't ctrl-c out of filename cmopletion, including the facts about the files involved, the exact sequence of what you type, and the behavior you observer? Dale
Re: Is this a bug?
On 2020-08-19 at 20:55 +, George R Goffe wrote: > Chet, > > I tried several times to create the problem. I think I succeeded. I did > install the "debuginfo" files I could find but it looks like libnss_sss.so's > debuginfo isn't built properly? It's supplied by sssd-client. I tried > installing sssd-client-debuginfo but it is already installed. I don't > remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? > That's what gdb thinks. > > Anyway, I tried causing the problem. ls -al zzz and then ctrl-c with > seemingly no response. I'll have to try running gdb in another konsole so I > can watch what happens when I ... I'll do that now. Stand by. > > > > I'm still not certain that I'm doing it right. When I entered ls -al zzz key> bash froze. I went to the gdb konsole and typed in where but nothing > happened. Tried several times. Tried ctrl-c on the gbb console. Got gdb's > attention. Entered where. Here's the results: > > Please let me know if this helps or if you need me to do something different. > > Regards, > > George... Since you mention sssd, and it is apparently loaded by bash, are the users and groups list from a remote server (such as LDAP)? That could cause bash (or whatever program which tries to determine the name of a user/group) to freeze if its cache expired and it needs to refetch those from a remote server (e.g. it may be downloading the list of all the users in the company). Best regards
Re: Is this a bug?
On 8/19/20 4:55 PM, George R Goffe wrote: > Chet, > > I tried several times to create the problem. I think I succeeded. I did > install the "debuginfo" files I could find but it looks like libnss_sss.so's > debuginfo isn't built properly? It's supplied by sssd-client. I tried > installing sssd-client-debuginfo but it is already installed. I don't > remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? > That's what gdb thinks. Yep, it needs it to get access to user and group data for things like tilde expansion. > Anyway, I tried causing the problem. ls -al zzz and then ctrl-c with > seemingly no response. I'll have to try running gdb in another konsole so I > can watch what happens when I ... I'll do that now. Stand by. The trace you sent shows readline waiting in pselect for user input, so it must be after the directory read was interrupted. The only thing I can suggest is to defer the attach in gdb until bash appears frozen. That may not work, but it's better than what you got. -- ``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/
Re: Is this a bug?
On 8/19/20 1:14 PM, George R Goffe wrote: > Chet, > > How can I help capture data about this problem? > > When I run bash in one konsole and it hangs, I do an strace on that pid and > the strace -xvfp always shows pselect. Eventually, the results come > back but til then, the session is frozen. You can try running gdb on bash from another terminal, attaching to the hanging bash process with `attach ', and generating a backtrace from gdb. That would at least give you the call stack. Make sure to run the bash instance you're testing with `--noprofile --norc' to get as vanilla an environment as possible. -- ``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/
Re: Is this a bug?
Chet, How can I help capture data about this problem? When I run bash in one konsole and it hangs, I do an strace on that pid and the strace -xvfp always shows pselect. Eventually, the results come back but til then, the session is frozen. I suppose I could run strace to a file on bash and make (or try) the failure appear. Your thoughts? Regards, George... George... On Wednesday, August 19, 2020, 5:58:03 AM PDT, Chet Ramey wrote: On 8/19/20 12:02 AM, George R Goffe wrote: > Chet, > > I've been thinking about what you've said below... that bash is waiting for > input. If this were the case, ctrl-c would return to the bash prompt > immediately. Yes? What I'm seeing is that with a partial filename entered > followed by the tab key is hit which results in nothing due to an > uninterriputible sleep. Ctrl-c does not stop the filename completion process. > > Does this make any sense? If that were the case, and it might be, the pselect is a red herring. The filename completion process doesn't use pselect. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
Re: Is this a bug?
On 8/19/20 12:02 AM, George R Goffe wrote: > Chet, > > I've been thinking about what you've said below... that bash is waiting for > input. If this were the case, ctrl-c would return to the bash prompt > immediately. Yes? What I'm seeing is that with a partial filename entered > followed by the tab key is hit which results in nothing due to an > uninterriputible sleep. Ctrl-c does not stop the filename completion process. > > Does this make any sense? If that were the case, and it might be, the pselect is a red herring. The filename completion process doesn't use pselect. Chet -- ``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/
Re: Is this a bug?
On Tue, Aug 18, 2020 at 7:57 PM George R Goffe wrote: > > Chet, > > Thanks for your response. > > I'm running konsoles (KDE). I have tried complettion but don't see any > evidence of bell ringing. Not even a flash. > > Do you think that bash have a problem with konsole? Maybe it's a konsole bug? > > > I'll look at konsole docs for anything that speaks of "alarm bells", visual > or otherwise and report back here. Ok? You can use pstack to see the call stack. regards, Dmitry
Re: Is this a bug?
On 8/18/20 5:14 PM, George R Goffe wrote: > Chet, > > > Please accept my apology for not responding to your email sooner. > > I have the bash source from the(?) repository. I followed Dimitris suggestion > and found bash hung in a system call named "pselect". I did a grep on the > source and found the only two ".c" files using "pselect": If it's in pselect, it's waiting for input. It's probably not performing completion at all. It may have read the directory, found no common prefix for the files it found, `rang' the visible bell, and gone back to waiting to read the next input character. -- ``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/
Re: Is this a bug?
Are you trying to run autocompletion on an nfs mount? Are you using ''ls'' to autocomplete and if so did you run \ls /path/to/dir .. ? Maybe worth to mention the bash version you are using. Op do 6 aug. 2020 19:53 schreef George R Goffe : > Hi, > > I apologize for bothering you with this question. > > I have several directories on a system with > 300k files. When I use > filename completion bash freezes for over a minute depending on the number > of files. I'm pretty sure that bash has to read the directory to do the > completion but the read appears to be uninterruptible. Is this a bug? > > Again, I apologize for bothering you with this. > > Best regards, > > George... > >
Re: Is this a bug?
On 8/6/20 1:53 PM, George R Goffe wrote: > Hi, > > I apologize for bothering you with this question. > > I have several directories on a system with > 300k files. When I use filename > completion bash freezes for over a minute depending on the number of files. > I'm pretty sure that bash has to read the directory to do the completion but > the read appears to be uninterruptible. Is this a bug? Can you tell what system call bash is executing? Some file systems make the system call underlying readdir() uninterruptible. In general, the readline filename completion function that calls readdir only reads a single directory entry at a time, and returns it to a caller. If the SIGINT causes readdir to return NULL, the function returns normally. If readdir returns a valid entry, the caller (e.g., rl_completion_matches) checks for receipt of a signal. That should be enough to terminate the directory read. > Again, I apologize for bothering you with this. No bother. Chet -- ``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/
Re: Is this a bug?
On Thu, Aug 6, 2020 at 1:54 PM George R Goffe wrote: > I have several directories on a system with > 300k files. When I use filename > completion bash freezes for over a minute depending on the number of files. > I'm pretty sure that bash has to read the directory to do the completion but > the read appears to be uninterruptible. Is this a bug? Why don't you run strace (or truss or whatever you have on your system) and see which syscall bash is blocked in? regards, Dmitry
Re: AW: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Op 07-02-20 om 12:19 schreef Walter Harms: IMHO is the bug on bash side. ash can assume to get an "healthy" environment from the caller. You can simply not fix everything that can possible go wrong. That is a rather fallacious argument. Of course you cannot fix *everything* that could possibly go wrong. You can certainly fix *this* thing, though. I know, because every non-Almquist shell does it. These days, no program can realistically assume a "healthy" environment. Computers have become unimaginably complex machines, built on thousands of interdependent abstraction layers, each as fallible as the humans that designed and implemented them. So "unhealthy" environments happen all the time, due to all sorts of unforeseen causes. It's well past time to accept that the 1980s are behind us. In 2020, systems have to be programmed robustly and defensively. Obviously it should not segfault but so far i understand it is bsd as that does, not busybox ash. True. But instead, it simply gets stuck forever, with no message or other indicator of what went wrong. How is that better? (Going slightly off-topic below...) Segfaulting is actually a good thing: it's one form of failing reliably. And failing reliably is vastly better than what often happens instead, especially in shell scripts: subtle breakage, which can take a lot of detective work to trace, and in some cases can cause serious damage due to the program functioning inconsistently and incorrectly (instead of not at all). Failing reliably is something the shell is ATROCIOUSLY bad at, and it's one of the first things modernish aims to fix. - Martijn -- modernish -- harness the shell https://github.com/modernish/modernish
Re: A possible bash bug.
On 10/11/19 12:07 AM, George R Goffe via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > > I've been seeing these crashes randomly for the past month. This happens when > I try to use filename completion. Is this a bash bug? It's hard to say, since the crash is apparently from systemd (?). > xpdAssertion 'pthread_mutex_init(>memfd_cache_mutex, NULL) == 0' failed at > src/libsystemd/sd-bus/sd-bus.c:257, function sd_bus_new(). Aborting. > Warning: Program '/bin/bash' crashed. > -- ``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/
Re: Is this a bug by any chance?
On Mon, Oct 07, 2019 at 04:23:44PM +0200, Andreas Schwab wrote:
> On Okt 07 2019, Greg Wooledge wrote:
>
> > x=(1 2 3 4 5 -n '/*' 'hello world')
> > for z in "${x[@]}"; do
> > printf %s "$z"
> > done
> > echo
>
> (IFS=; printf '%s\n' "${x[*]}")
Or avoid the fork():
printf %s "${x[@]}"
echo
I preserved the original poster's loop, because it's probably
another !b9 question.
Re: Is this a bug by any chance?
On Okt 07 2019, Greg Wooledge wrote:
> x=(1 2 3 4 5 -n '/*' 'hello world')
> for z in "${x[@]}"; do
> printf %s "$z"
> done
> echo
(IFS=; printf '%s\n' "${x[*]}")
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Is this a bug by any chance?
On Mon, Oct 07, 2019 at 08:05:12PM +0700, pepa65 wrote:
> > On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports
> > for the GNU Bourne Again SHell wrote:
> >> I was expecting to see:
> >> 12345
> >
> > If you want to create a *list* and iterate over that list, one element
> > at a time, use arrays instead of string variables.
> >
> > x=(1 2 3 4 5)
> > for z in "${x[@]}"; do
> > echo "$z"
> > done
>
> Just to be clear (as nobody has mentioned this) to get them all on the
> same line, you need "echo -n", and you can do this without using arrays:
>
> x="1 2 3 4 5"
> for z in $x
> do echo -n "$z"
> done
This has some issues. echo -n will fail if one of the list elements is
an option recognized by echo. The unquoted $x expansion will fail if
one of the list elements is a glob that matches some files, or a glob
that matches no files if nullglob is active.
Also, the list-in-a-string gives you absolutely no way to handle list
elements that contain internal whitespace. This is what arrays are for.
Please use the arrays.
x=(1 2 3 4 5 -n '/*' 'hello world')
for z in "${x[@]}"; do
printf %s "$z"
done
echo
Re: Is this a bug by any chance?
> On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports for
> the GNU Bourne Again SHell wrote:
>> I was expecting to see:
>> 12345
>
> If you want to create a *list* and iterate over that list, one element
> at a time, use arrays instead of string variables.
>
> x=(1 2 3 4 5)
> for z in "${x[@]}"; do
> echo "$z"
> done
Just to be clear (as nobody has mentioned this) to get them all on the
same line, you need "echo -n", and you can do this without using arrays:
x="1 2 3 4 5"
for z in $x
do echo -n "$z"
done
Cheers,
Peter
Re: Is this a bug by any chance?
On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports for
the GNU Bourne Again SHell wrote:
> I was expecting to see:
> 12345
> #!./bash -xv
> x="1 2 3 4 5"
> for z in "$x"
> do
> echo "$z"
> done
> exit 0
Not a bug. You've created a string of length 9 characters, and
you've told bash to iterate once, using this string as the contents of
variable z.
If you want to create a *list* and iterate over that list, one element
at a time, use arrays instead of string variables.
x=(1 2 3 4 5)
for z in "${x[@]}"; do
echo "$z"
done
See and
.
Re: Is this a bug by any chance?
On Sat, 5 Oct 2019 18:48:35 + (UTC) George R Goffe via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > > I just built the latest bash in an effort to determine if thie script shows a > bug or a ufu. Can you help me please? > > I was expecting to see: > 12345 > > Best regards AND thanks for your help, > > George... > > #!./bash -xv > x="1 2 3 4 5" > + x='1 2 3 4 5' > for z in "$x" > do > echo "$z" > done > + for z in "$x" > + echo '1 2 3 4 5' > 1 2 3 4 5 > exit 0 > + exit 0 > > It's definitely not a bug. Quoting the expansion inhibits word splitting. Your loop iterates once over a single word. Said word is conveyed to echo as a single argument. In this case, said argument is printed by echo, with the addition of a newline character. If your ultimate intent is to store an arbitrary list of strings in a variable prior to iterating over them, you should use an array variable instead. As such, this would be a topic better suited to the help-bash list. -- Kerin Millar
Re: Option '-c' has bug when compile-time config 'ONESHOT' is enabled
On 5/14/19 5:57 PM, Yu Kou wrote: > Bash Version: 5.0 > Patch Level: 2 > Release Status: release > > Description: > This bug was found in bash 4.4.12 (GNU bash, version > 4.4.12(1)-release (x86_64-pc-linux-gnu)) > It is still here in bash 5.0.2. > > I pubilshed it first in this page, > > https://unix.stackexchange.com/questions/406674/bash-why-is-alias-after-newline-ignored-when-run-remotely#407064 > > This is a bug of option '-c'. > > It can be reproduced with the command below, > > bash -c "shopt -s expand_aliases &>/dev/null; > alias myalias='echo foo > echo bar > echo baz' > myalias > > I expect it to output such three lines as follows, > foo > bar > baz > > But only 'foo' will be output. Thanks for the report and analysis. It's a simple fix. Chet -- ``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/
Re: [PATCH] Fix a bug that `bind -x '"metachar":command'' fails when rl-variable `convert-meta' is `on'
On 2/11/19 1:57 AM, Koichi Murase wrote:
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
>
> When readline variable `convert-meta' is set to `on', `bind -x'
> including meta characters in its keyseq fails to bind.
>
> For an actual example, see the next `Repeat-By' section. An
> inconsistency comes from the condition whether to contain ESC (from
> meta chars) in the keyseq stored in keymaps. For example, in
> `rl_generic_bind' (lib/readline/bind.c), ESC is only contained when
> the keymap already has a child ISKMAP entry at ESC as quoted below:
>
> if (META_CHAR (ic) && _rl_convert_meta_chars_to_ascii)
> {
> ic = UNMETA (ic);
> if (map[ESC].type == ISKMAP) /* <-- this condition */
> {
> prevmap = map;
> map = FUNCTION_TO_KEYMAP (map, ESC);
> }
> }
>
> In addition, the condition in `rl_translate_keyseq'
> (lib/readline/bind.c) always refers to the current top-level keymap
> `_rl_keymap' rather than the corresponding keymap entry in the target
> keymap tree, which appears to be unreasonable:
>
> if (_rl_convert_meta_chars_to_ascii && _rl_keymap[ESC].type == ISKMAP)
> array[l++] = ESC; /* ESC is meta-prefix */
>
> `bind -x' stores data in two different keymaps: the selected keymap
> and the keymap `cmd_xmap' defined in `bashline.c'. When one has a
> child ISKMAP entry at ESC and the other doesn't have, the inconsisty
> arises.
>
> Repeat-By:
>
> The readline variable `convert-meta' is enabled by default when Bash
> starts with `LANG=C'.
>
> $ LANG=C bash-5.0 --norc
> $ bind -v | grep convert-meta
> set convert-meta on
>
> `bind -x' whose keyseq contains meta characters stores the command
> string to wrong places in `cmd_xmap'. In the following example, the
> command string for `\M-c' is stored to the placeholder for `c'.
>
> $ bind -x '"c": "echo hello"'
> $ bind -x $'"\xE3": "echo world"'
> world # <-- somehow the binding for `\M-c' is invoked by typing `c'
> $
> bash-5.0: bash_execute_unix_command: cannot find keymap for
> command # <-- error is produced by typing `\M-c'
> $ bind -X
> "c": "echo world"
> $
>
> For reference, usual macro key bindings work as expected.
>
> $ bind '"c": "hello"'
> $ bind $'"\xE3": "world"'
> $ echo helloworld # <-- `hello' and `world' is inserted by typing
> `c' and `\M-c'
> helloworld
> $ bind -s
> "\ec": "world"
> "c": "hello"
>
> Fix:
>
> Actually I'm not sure if there is a reason why stored keyseqs
> contains ESC only when there is already ESC entry, but a possible
> solution would be to create a new ISKMAP entry when there is no ISKMAP
> entry at ESC. I attach a patch
> `0001-translate-meta-characters-when-convert-meta-is-set.patch'. I
> have changed `rl_bind_key' (lib/readeline/bind.c) so that the ISKMAP
> entry is explicitly created. I have changed `rl_translate_keyseq'
> (lib/readeline/bind.c) so that meta characters `c' are always
> translated to `ESC' + `UNMETA (c)' when `convert-meta' is set. In this
> way, the array `keys' in `rl_generic_bind' (lib/readeline/bind.c)
> would never contain meta characters when `convert-meta' is set, so the
> codes to check meta characters have been removed from
> `rl_generic_bind'.
I agree that this is a problem. I think an easier solution for rl_bind_key
is to simply create a new key sequence in KEYSEQ, with the first character
as ESC, then pass the whole thing off to rl_generic_bind, which will handle
creating the appropriate shadow keymaps if necessary (your second patch
tries to do this inline, it appears).
The other patches are good. Thanks for the detailed report. Please take a
look at the next devel branch push and make sure it fixes your issues.
Chet
--
``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/
Re: [PATCH] Fix a bug that `bind -x '"metachar":command'' fails when rl-variable `convert-meta' is `on'
> Description: > > When readline variable `convert-meta' is set to `on', `bind -x' > including meta characters in its keyseq fails to bind. I'm sorry. There was a bug in the patch `0001-*.patch' in the previous mail. Could you please check the new one attached to this mail instead of the previous one? Best regards, Koichi 0001-translate-meta-characters-when-convert-meta-is-set.patch Description: Binary data
Re: 回复： display bug for both gnome-teminal & terminator & xterm
On 8/24/18 9:39 AM, weidong wrote: > hello, Thanks. What is your locale? The output of running `locale' should be sufficient. -- ``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/
Re: exec/read -s bug?
> On Aug 19, 2018, at 8:45 PM, Lars Schneider wrote:
>
>
>> On Aug 19, 2018, at 6:33 PM, Lars Schneider wrote:
>>
>> Hi,
>>
>> consider this script:
>>
>> #!/bin/bash
>> [ "`whoami`" = "root" ] || {
>>exec sudo -u root "$0" "$@"
>> }
>> read -s -p "enter stuff: " stuff
>>
>> If I run the script as normal user (not root!) and I abort the "read -s -p"
>> call with "ctrl-c", then my shell is still in silent mode.
>>
>> I can consitently replicate that behavior on Ubuntu 14.04.5 LTS (Trusty)
>> and BASH 4.3.11(1)-release (x86_64-pc-linux-gnu) as well as BASH 4.3.30.
>>
>> I also installed BASH 4.4.18 from source and I can replicate the issue.
>
> I did a mistake: The problem _was_ fixed with BASH 4.4.18.
> Further testing revealed that it is fixed with 4.4. too but not in Bash-4.3
> patch 46.
>
> I think the following item in the release notes corresponds to the problem:
>
> oo. Fixed a bug that caused bash to not clean up readline's state, including
> the terminal settings, if it received a fatal signal while in a readline()
> call (including `read -e' and `read -s').
>
> Does anyone see a workaround to set the readline state properly
> for older BASH versions?
OK, I found a work around:
[ "`whoami`" = "root" ] || {
exec sudo -u root "$0" "$@"
}
function finish {
stty echo echok
}
trap finish EXIT
read -s -p "enter stuff: " stuff
echo "answer: $stuff"
Cheers,
Lars
Re: exec/read -s bug?
> On Aug 19, 2018, at 6:33 PM, Lars Schneider wrote:
>
> Hi,
>
> consider this script:
>
> #!/bin/bash
> [ "`whoami`" = "root" ] || {
> exec sudo -u root "$0" "$@"
> }
> read -s -p "enter stuff: " stuff
>
> If I run the script as normal user (not root!) and I abort the "read -s -p"
> call with "ctrl-c", then my shell is still in silent mode.
>
> I can consitently replicate that behavior on Ubuntu 14.04.5 LTS (Trusty)
> and BASH 4.3.11(1)-release (x86_64-pc-linux-gnu) as well as BASH 4.3.30.
>
> I also installed BASH 4.4.18 from source and I can replicate the issue.
I did a mistake: The problem _was_ fixed with BASH 4.4.18.
Further testing revealed that it is fixed with 4.4. too but not in Bash-4.3
patch 46.
I think the following item in the release notes corresponds to the problem:
oo. Fixed a bug that caused bash to not clean up readline's state, including
the terminal settings, if it received a fatal signal while in a readline()
call (including `read -e' and `read -s').
Does anyone see a workaround to set the readline state properly
for older BASH versions?
Thanks,
Lars
Re: [PATCH] fix a bug that bind -x '"\C-@": unix-command' does not work
On 3/20/18 12:35 PM, Koichi Murase wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > > Description: > > In bash-4.3.43, bash-4.4.12, and the latest commit of the devel > branch, `bind -x' does not work for key sequences containing `\C-@'. Thanks for the report and patch for this. Adding a new public interface is the right way to do it. I'm less certain about your second set of patches. This breaks backward compatibility -- defined as what callers have come to expect -- in several ways. Philosophically, there should not be that much difference between a function that accepts a `translated' key sequence and one that doesn't. Even if a key sequence starts in an `untranslated' state, the caller should be able to pass the translated version to rl_translate_keyseq and have the result unchanged. It's an unusual key binding that can't handle this, and I believe \C-@ is the only key sequence for which it matters. None of the arrow key sequences in common use, for example, contain it (that is your objection with _rl_term_ku, etc.). Since I believe that for the most part `raw' key sequences such as those in _rl_term_ku will pass through rl_translate_keyseq without modification, I'm going to try the changes to rl_bind_keyseq_if_unbound_in_map and the other changes in your second patch and see how it goes. Chet -- ``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/
Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]
On 11/4/16 3:05 AM, Martijn Dekker wrote: > Op 04-11-16 om 01:27 schreef Eduardo Bustamante: >> I agree with everything, except calling it severe. This is >> self-inflicted harm, and easy to work around > > It is not self-inflicted. The behaviour is a bug in bash. The user did > nothing to cause that bug. I don't think anyone is disputing that it's a bug in bash. I agree with Eduardo's point, though, which is that there doesn't appear to be anything special enough about this particular problem to warrant releasing patches for versions of bash that were released seven years ago. So it's a bug, it's been present for at least 17 years, it's extremely rare in practice, and I will fix it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]
If you want to split with read, use a tempenv IFS: dualbus@hp:~/local/src/gnu/bash$ bash -c 'IFS="?" read a b c <<< "hello?world?xyz"; echo "$a"' hello If you want to split using word splitting: dualbus@hp:~/local/src/gnu/bash$ bash -c 'v="hello?world?xyz"; IFS="?"; set -- $v; unset IFS; echo "$1"' hello If you want to use the $* parameter: dualbus@hp:~/local/src/gnu/bash$ bash -c 'set -- abc def ghi; IFS="?"; echo "$*"; unset IFS' abc?def?ghi I didn't say there's no bug. There is. And when I said, "self-inflicted harm", I meant that leaving as IFS='][?*' is not really needed. If you need to do some word splitting, set the IFS, and then restore its original value or unset it. Perhaps I'm missing something here, but I think for the relevant use cases of IFS, there are sane work arounds. What other use case would require of setting IFS to such value permanently?
Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]
Op 04-11-16 om 01:27 schreef Eduardo Bustamante: > I agree with everything, except calling it severe. This is > self-inflicted harm, and easy to work around It is not self-inflicted. The behaviour is a bug in bash. The user did nothing to cause that bug. Even if you think it's somehow reasonable to expect bash users to be aware of this bug while using or coding for bash (though the bug has not been publicised anywhere), bash is supposed to be a POSIX shell, and POSIX is supposed to be a standard. You cannot assume that the code bash executes is written with bash bugs in mind. It is also not "easy" to work around. If your program for any reason needs to split strings on any of the characters ?, *, [ and ], and uses field splitting to achieve this (which in POSIX is the canonical method), you will now need to program a workaround with something like sed or parameter substitutions. Unless, of course, the easy workaround is to simply use another shell. Another big issue is that third-party library functions need to work for arbitrary values of IFS. This bug makes that impossible for bash. For instance, if you recall, the original bug reporter wanted to split some string by "*" on an interactive shell. This caused a freeze upon using auto-completion because the bash-completion package broke as a result. Chet initially blamed it on bash-completion, but in fact the fault was with bash itself. The resulting breakage was clearly severe. - M.
Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]
I agree with everything, except calling it severe. This is self-inflicted harm, and easy to work around
Re: bash completion escaping bug
On 8/24/15 4:01 PM, Neven Sajko wrote: Hi, I use bash 4.3.039 and there is a bug (not necessarily a recent regression) with its file name completion feature. for example I have this in shell input: db.rc $home/Downloads/games/DOS/Captai and after I press Tab I have this: db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dome\ of\ Darkness.zip Notice the dollar sign which is now erroneously escaped (home is a variable). This is a case for which you need to enable the `direxpand' option. You've presented the bash completion code with an ambiguous case: it needs to backslash-escape characters in the filename that are special to the shell, but you want some of them to be escaped (the spaces) and not others (`$'). The bash interface to the readline completion engine escapes all special characters in the filename, and, without `direxpand', the filename it's presented looks like this: $home/Downloads/games/DOS/Captain Bible in the Dome of Darkness.zip The quoted version is what you see. Enabling `direxpand' will eliminate the ambiguity by expanding the variable to its value before trying to quote the special characters. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash completion escaping bug
for example I have this in shell input: db.rc $home/Downloads/games/DOS/Captai and after I press Tab I have this: db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dome\ of\ Darkness.zip Sorry, the completed command line was wrapped: db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dome\ of\ Darkness.zip Also, I forgot to say that the bug only happens when there are characters in the filename that may be legitimately escaped, blanks in this case.
Re: Weird background crashing bug
On Mon, Jun 29, 2015 at 09:28:11AM +0300, Pierre Gaston wrote: On Mon, Jun 29, 2015 at 5:54 AM, Braden Best bradentb...@gmail.com wrote: I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m` I'm assuming the backticks are NOT actually part of the command. I.e. you are really just typing: xter m * both xterm and gnome-terminal crash I don't seem to be able to reproduce with 4.3.30(1)-release, just in case, can you try it after running: PS1='$ ' PROMPT_COMMAND=''; unset -f command_not_found_handle It would also be useful to report what this command says: type command_not_found_handle There's a good chance the problem is being caused by some OS vendor-installed command_not_found_handle that can't handle being run as a background job.
Re: Weird background crashing bug
Reply to the mailing list, and supply the information we requested
(the *exact output* of type command_not_found_handle, and Pierce's
suggestion to try to duplicate the problem with command_not_found_handle
unset).
On Mon, Jun 29, 2015 at 03:04:03PM -0600, Braden Best wrote:
Here's the same screenshot in panel format: http://i.imgur.com/aL8NySU.png
--Braden
On Mon, Jun 29, 2015 at 2:28 PM, Braden Best bradentb...@gmail.com wrote:
Yes, the back tick is a quoting mechanism I picked up from stack exchange.
In those sites, it highlights the text and renders it in a fixed width font.
cnf handle is : command not found
Also, I misinterpreted one of the bullet points as which *version* of
GCC was used instead of simply which compiler. As this version of bash
is what comes default from the Ubuntu repo, I'd assume it's GCC.
Setting PS1 to something else prevents the crash for me. So since the root
of the problem appears to be $PS1...
~ $ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
Also, just to show that the terminal really *is* crashing, and not
somehow vanishing into the background itself, I made a gif. I don't usually
embed or attach gifs via email, so here's a link:
http://i.imgur.com/epCwOlI.gif
What do you make of this?
--Braden
On Jun 29, 2015 5:59 AM, Greg Wooledge wool...@eeg.ccf.org wrote:
On Mon, Jun 29, 2015 at 09:28:11AM +0300, Pierre Gaston wrote:
On Mon, Jun 29, 2015 at 5:54 AM, Braden Best bradentb...@gmail.com
wrote:
I noticed it when I tried to branch an xterm off into multiple
sessions
and mistyped its name:
`xter m`
I'm assuming the backticks are NOT actually part of the command. I.e.
you are really just typing:
xter m
* both xterm and gnome-terminal crash
I don't seem to be able to reproduce with 4.3.30(1)-release, just in
case,
can you try it after running:
PS1='$ ' PROMPT_COMMAND=''; unset -f command_not_found_handle
It would also be useful to report what this command says:
type command_not_found_handle
There's a good chance the problem is being caused by some OS
vendor-installed command_not_found_handle that can't handle being
run as a background job.
--
Braden Best
bradentb...@gmail.com
(505) 692 0947
Re: Weird background crashing bug
Forwarding to the mailing list:
On Mon, Jun 29, 2015 at 02:28:32PM -0600, Braden Best wrote:
Yes, the back tick is a quoting mechanism I picked up from stack exchange.
In those sites, it highlights the text and renders it in a fixed width font.
cnf handle is : command not found
Also, I misinterpreted one of the bullet points as which *version* of GCC
was used instead of simply which compiler. As this version of bash is
what comes default from the Ubuntu repo, I'd assume it's GCC.
Setting PS1 to something else prevents the crash for me. So since the root
of the problem appears to be $PS1...
~ $ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
Also, just to show that the terminal really *is* crashing, and not somehow
vanishing into the background itself, I made a gif. I don't usually embed
or attach gifs via email, so here's a link: http://i.imgur.com/epCwOlI.gif
What do you make of this?
--Braden
On Jun 29, 2015 5:59 AM, Greg Wooledge wool...@eeg.ccf.org wrote:
On Mon, Jun 29, 2015 at 09:28:11AM +0300, Pierre Gaston wrote:
On Mon, Jun 29, 2015 at 5:54 AM, Braden Best bradentb...@gmail.com
wrote:
I noticed it when I tried to branch an xterm off into multiple sessions
and mistyped its name:
`xter m`
I'm assuming the backticks are NOT actually part of the command. I.e.
you are really just typing:
xter m
* both xterm and gnome-terminal crash
I don't seem to be able to reproduce with 4.3.30(1)-release, just in
case,
can you try it after running:
PS1='$ ' PROMPT_COMMAND=''; unset -f command_not_found_handle
It would also be useful to report what this command says:
type command_not_found_handle
There's a good chance the problem is being caused by some OS
vendor-installed command_not_found_handle that can't handle being
run as a background job.
Re: Weird background crashing bug
On Mon, Jun 29, 2015 at 5:54 AM, Braden Best bradentb...@gmail.com wrote: Re-send: I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m` So after experimenting with a ton of different scenarios I've come to this conclusion: * both xterm and gnome-terminal crash * a nested bash session also crashes returning me back to the previous shell where the wd is ~ * does *not* crash in TTY, nor in nested session *within* TTY. * only happens when two or more (but not less) directories deep into home (~), for example, ~/Videos/movies/ or ~/Pictures/vacation/2009. *Running a non-existent command in the background while two or more directories deep into home (~) causes bash to crash, but only when in a terminal emulator* Why does this happen? Addendum: *The version number of Bash.* $ bash --version 4.3.11(1)-release (x86_64-pc-linux-gnu) *The hardware and operating system.* Aspire-XC-603G Ubuntu 14.04.1 LTS *The compiler used to compile Bash.* can't find that information. `info bash | grep gcc` gives me nothing *A description of the bug behaviour.* Described Above *A short script or ‘recipe’ which exercises the bug and may be used to reproduce it. *$ mkdir dir1 $ mkdir dir1/dir2 $ cd dir1/dir2 $ nonexistentcommand Using it as a script won't cause a crash. The crash only happens in interactive mode. On Sun, Jun 28, 2015 at 8:40 PM, Braden Best bradentb...@gmail.com wrote: I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m` So after experimenting with a ton of different scenarios I've come to this conclusion: * both xterm and gnome-terminal crash * a nested bash session also crashes returning me back to the previous shell where the wd is ~ * does *not* crash in TTY, nor in nested session *within* TTY. * only happens when two or more (but not less) directories deep into home (~), for example, ~/Videos/movies/ or ~/Pictures/vacation/2009. *Running a non-existent command in the background while two or more directories deep into home (~) causes bash to crash, but only when in a terminal emulator* Why does this happen? -- Braden Best bradentb...@gmail.com (505) 692 0947 -- Braden Best bradentb...@gmail.com (505) 692 0947 I don't seem to be able to reproduce with 4.3.30(1)-release, just in case, can you try it after running: PS1='$ ' PROMPT_COMMAND=''; unset -f command_not_found_handle
Re: Weird background crashing bug
Re-send: I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m` So after experimenting with a ton of different scenarios I've come to this conclusion: * both xterm and gnome-terminal crash * a nested bash session also crashes returning me back to the previous shell where the wd is ~ * does *not* crash in TTY, nor in nested session *within* TTY. * only happens when two or more (but not less) directories deep into home (~), for example, ~/Videos/movies/ or ~/Pictures/vacation/2009. *Running a non-existent command in the background while two or more directories deep into home (~) causes bash to crash, but only when in a terminal emulator* Why does this happen? Addendum: *The version number of Bash.* $ bash --version 4.3.11(1)-release (x86_64-pc-linux-gnu) *The hardware and operating system.* Aspire-XC-603G Ubuntu 14.04.1 LTS *The compiler used to compile Bash.* can't find that information. `info bash | grep gcc` gives me nothing *A description of the bug behaviour.* Described Above *A short script or ‘recipe’ which exercises the bug and may be used to reproduce it. *$ mkdir dir1 $ mkdir dir1/dir2 $ cd dir1/dir2 $ nonexistentcommand Using it as a script won't cause a crash. The crash only happens in interactive mode. On Sun, Jun 28, 2015 at 8:40 PM, Braden Best bradentb...@gmail.com wrote: I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m` So after experimenting with a ton of different scenarios I've come to this conclusion: * both xterm and gnome-terminal crash * a nested bash session also crashes returning me back to the previous shell where the wd is ~ * does *not* crash in TTY, nor in nested session *within* TTY. * only happens when two or more (but not less) directories deep into home (~), for example, ~/Videos/movies/ or ~/Pictures/vacation/2009. *Running a non-existent command in the background while two or more directories deep into home (~) causes bash to crash, but only when in a terminal emulator* Why does this happen? -- Braden Best bradentb...@gmail.com (505) 692 0947 -- Braden Best bradentb...@gmail.com (505) 692 0947
Re: Serious tab completion bug
On 3/14/15 10:12 AM, Linda Walsh wrote: Chet Ramey wrote: Thanks for the report. This isn't a bug; it's intentional behavior. You have presented bash with an ambiguous situation: it doesn't know whether or not you want to look for a filename in the current directory or perform variable expansion. Bash assumes you want filename completion if there's an existing pathname matching the string you typed, so it treats your scenario as filename completion rather than variable expansion. But that's not what it does. If that was what it did, it would be great, but I agree with the original poster. if I am in /tmp, and I try echo $HOME/complete, and the pathname '$HOME' doesn't exist in /tmp, it will still quote it. Not by default, so I assume that this is what bash-completion produces. I corresponded privately with the original poster and he confirmed that he was using bash-completion. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Serious tab completion bug
On 3/6/15 4:54 PM, Joseph Graham wrote: Hi, I don't know what the etiquette is for using this mailing list but I hope it's OK to just get straight to the bug. *STEPS TO REPRODUCE* 1. run the following commands to get everything set up: $ touch hiya $ mkdir '$HOME' $ touch '$HOME/hiya' 2. Now to reproduce the bug, type: $ rm $HOME/hi THEN PRESS TAB! It incorrectly escapes the $ resulting in: $ rm \$HOME/hiya If the user does not notice and presses return it will DELETE THE WRONG FILE!!! Thanks for the report. This isn't a bug; it's intentional behavior. You have presented bash with an ambiguous situation: it doesn't know whether or not you want to look for a filename in the current directory or perform variable expansion. Bash assumes you want filename completion if there's an existing pathname matching the string you typed, so it treats your scenario as filename completion rather than variable expansion. Bash has behaved this way since bash-3.0, the result of a bug report received back in July, 2004. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash-4.3.33 regexp bug
On 3/6/15 4:35 PM, Stephane Chazelas wrote:
2015-03-06 11:43:24 -0500, Chet Ramey:
On 3/5/15 12:36 PM, Greg Wooledge wrote:
On Thu, Mar 05, 2015 at 05:26:00PM +, Stephane Chazelas wrote:
The bash manual only points to regex(3).
So it's down to your system's regex library (uses
regcomp(REG_EXTENDED)) which on recent GNU systems supports \s.
I see. So it's another nonportable feature like printf '%(%s)T'.
It's an imperfect world. I'd rather not replace the system's regexp
library, just like I'd rather use the system's strftime(3) if it's
available.
[...]
BTW:
$ ltrace -e regcomp bash -c 'bs=\\; [[ a =~ ${bs}[\.s ]]'
bash-regcomp(0x7fff4d48bef0, \\[.s, 1)
I think it should be
bash-regcomp(0x7fff4d48bef0, \\[\\.s, 1)
Thanks for the report. I think you're right, and the code needs to handle
the absence of a closing bracket better. This will be fixed for the next
release of bash.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash-4.3.33 regexp bug
On 3/5/15 9:26 AM, Jason Vas Dias wrote:
Good day list, Chet -
I think this is a bug:
( set -x ; tab=$'\011'; s=some text: 1.2.3;
if [[ $s =~ ^some text:[\ $tab]+([0-9.]+) ]]; then
echo ${BASH_REMATCH[1]};
fi
)
-bash: syntax error in conditional expression
-bash: syntax error near `$tab]+([0-9.]+)'
Do you agree ?
No.
This is a conditional command that looks like
[[ $s =~ ^some garbage ]]
(four tokens).
When bash tries to make sense of the stuff after the space between
`^some' and `text', it can't find any operators that make sense in
that context -- or the closing `]]' -- and reports a syntax error.
The parser still has to tokenize the words in a conditional command,
and an unescaped space separates words. If you escape that space, the
regular expression should match like you want. It does in my testing.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash-4.3.33 regexp bug
On 3/5/15 12:36 PM, Greg Wooledge wrote: On Thu, Mar 05, 2015 at 05:26:00PM +, Stephane Chazelas wrote: The bash manual only points to regex(3). So it's down to your system's regex library (uses regcomp(REG_EXTENDED)) which on recent GNU systems supports \s. I see. So it's another nonportable feature like printf '%(%s)T'. It's an imperfect world. I'd rather not replace the system's regexp library, just like I'd rather use the system's strftime(3) if it's available. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash-4.3.33 regexp bug
2015-03-06 11:43:24 -0500, Chet Ramey:
On 3/5/15 12:36 PM, Greg Wooledge wrote:
On Thu, Mar 05, 2015 at 05:26:00PM +, Stephane Chazelas wrote:
The bash manual only points to regex(3).
So it's down to your system's regex library (uses
regcomp(REG_EXTENDED)) which on recent GNU systems supports \s.
I see. So it's another nonportable feature like printf '%(%s)T'.
It's an imperfect world. I'd rather not replace the system's regexp
library, just like I'd rather use the system's strftime(3) if it's
available.
[...]
BTW:
$ ltrace -e regcomp bash -c 'bs=\\; [[ a =~ ${bs}[\.s ]]'
bash-regcomp(0x7fff4d48bef0, \\[.s, 1)
I think it should be
bash-regcomp(0x7fff4d48bef0, \\[\\.s, 1)
--
Stephane
Re: bash-4.3.33 regexp bug
2015-03-05 12:36:39 -0500, Greg Wooledge:
On Thu, Mar 05, 2015 at 05:26:00PM +, Stephane Chazelas wrote:
The bash manual only points to regex(3).
So it's down to your system's regex library (uses
regcomp(REG_EXTENDED)) which on recent GNU systems supports \s.
I see. So it's another nonportable feature like printf '%(%s)T'.
Good to know!
imadev:~$ s='foo bar'; r='\s'; if [[ $s =~ $r ]]; then echo match; fi
imadev:~$ printf '%(%s)T\n' -1
s
wooledg@wooledg:~$ s='foo bar'; r='\s'; if [[ $s =~ $r ]]; then echo match; fi
match
wooledg@wooledg:~$ printf '%(%s)T\n' -1
1425576833
[...]
It's a bit worse than %(%s)T (another ksh93 feature (a subset
thereof as ksh93 also parses the argument as a date)) in that
while %(xxx)T passes xxx to strftime verbatim, in [[ ... =~ xxx
]], bash does some modification on xxx making some assumtion on
the syntax of that regex (provided by a 3rd party).
Since 3.2, shell-quotings (so with \, ', ) a regexp escapes
the regular expression operators.
That (I think) was done for compatibility with ksh93, but while
ksh93 has its own ATT regexps, bash uses 3rd parties'.
So for instance, when you write:
[[ foo =~ .. ]]
bash calls regcomp() with \...
There used to be a bug in that: [.] would be turned into [\.]
(matching backslash in addition to dot).
Now bash should work as long as you use POSIX compatible
regexps and the system's regexp library is POSIX compliant.
When you want to make use of extensions in your system's regexps
is where it starts to be tricky and it helps to know how bash
works in that regard.
[[ foo =~ \s ]]
would call regcomp with s (backslash is taken as shell
quoting, s is not a POSIX regex operator so a \ is not added),
and \\s or \s with \\s (double backslash s) (quoted \, \
is also a regexp operator so \ added) . That's why you need the
variable to be able to use that non-POSIX \s extension.
[[ foo = $var ]] passes the content of $var verbatim to regcomp,
while [[ foo = $var ]] passes the content of $var with regexp
operators escaped.
You can also do:
bs='\'
[[ =~ ${bs}s ]]
to pass \s to regcomp().
--
Stephane
Re: bash-4.3.33 regexp bug
2015-03-05 12:14:21 -0500, Greg Wooledge: On Thu, Mar 05, 2015 at 05:07:44PM +, Stephane Chazelas wrote: bash also supports \s, but that's more for [[:space:]] (so includes vertical spacing like CR, LF), and you need to use an intermediary variable: r='^some text:\s+([0-9.]+)' [[ $s =~ $r ]] Woah! What? Where is *that* documented? The only \s in the man page is in PS1. The bash manual only points to regex(3). So it's down to your system's regex library (uses regcomp(REG_EXTENDED)) which on recent GNU systems supports \s. The need for the intermediary variable is down to the broken way bash tries to overload \ as a quoting operator and regexp operator since bash-3.2. -- Stephane
Re: bash-4.3.33 regexp bug
On Thu, Mar 05, 2015 at 05:26:00PM +, Stephane Chazelas wrote: The bash manual only points to regex(3). So it's down to your system's regex library (uses regcomp(REG_EXTENDED)) which on recent GNU systems supports \s. I see. So it's another nonportable feature like printf '%(%s)T'. Good to know! imadev:~$ s='foo bar'; r='\s'; if [[ $s =~ $r ]]; then echo match; fi imadev:~$ printf '%(%s)T\n' -1 s wooledg@wooledg:~$ s='foo bar'; r='\s'; if [[ $s =~ $r ]]; then echo match; fi match wooledg@wooledg:~$ printf '%(%s)T\n' -1 1425576833
Re: bash-4.3.33 regexp bug
2015-03-05 14:26:48 +, Jason Vas Dias:
Good day list, Chet -
I think this is a bug:
( set -x ; tab=$'\011'; s=some text: 1.2.3;
if [[ $s =~ ^some text:[\ $tab]+([0-9.]+) ]]; then
echo ${BASH_REMATCH[1]};
fi
)
-bash: syntax error in conditional expression
-bash: syntax error near `$tab]+([0-9.]+)'
[...]
You forgot to quote the first space. Should be
if [[ $s =~ ^some\ text:[\ $tab]+([0-9.]+) ]]; then
I'd use [[:blank:]] to match blanks though.
bash also supports \s, but that's more for [[:space:]] (so
includes vertical spacing like CR, LF), and you need to use an
intermediary variable:
r='^some text:\s+([0-9.]+)'
[[ $s =~ $r ]]
or use
shopt -s compat31
[[ $s =~ '^some text:\s+([0-9.]+)' ]]
or use zsh
in bash-3.2, the behaviour was changed (broken IMO) to match
ksh93's.
--
Stephane
Re: bash-4.3.33 regexp bug
On Thu, Mar 05, 2015 at 05:07:44PM +, Stephane Chazelas wrote: bash also supports \s, but that's more for [[:space:]] (so includes vertical spacing like CR, LF), and you need to use an intermediary variable: r='^some text:\s+([0-9.]+)' [[ $s =~ $r ]] Woah! What? Where is *that* documented? The only \s in the man page is in PS1.
Re: bash-4.3.33 regexp bug
On Thu, Mar 05, 2015 at 02:26:48PM +, Jason Vas Dias wrote:
Good day list, Chet -
I think this is a bug:
( set -x ; tab=$'\011'; s=some text: 1.2.3;
if [[ $s =~ ^some text:[\ $tab]+([0-9.]+) ]]; then
echo ${BASH_REMATCH[1]};
fi
)
-bash: syntax error in conditional expression
-bash: syntax error near `$tab]+([0-9.]+)'
From a quick glance, it does seem like a parsing bug, it should not break with
a syntax error.
Though, you can work-around this issue by doing the recommended approach to
regex matching: storing the regex in a variable.
| dualbus@dualbus ~ % bash bug
| + s='some text: 1.2.3'
| + r='^some text:[ ]+([0-9.]+)'
| + [[ some text: 1.2.3 =~ ^some text:[ ]+([0-9.]+) ]]
| + echo 1.2.3
| 1.2.3
|
| dualbus@dualbus ~ % cat bug
| #!/bin/bash
| ( set -x ; s=some text: 1.2.3;
|r=$'^some text:[ \t]+([0-9.]+)'
|if [[ $s =~ $r ]]; then
| echo ${BASH_REMATCH[1]};
|fi
| )
See http://mywiki.wooledge.org/BashGuide/Patterns#Regular_Expressions-1 and
http://tiswww.case.edu/php/chet/bash/FAQ (E14).
Re: dot gob+extglob bug
The pathexp-globignore-delim.patch seems to work as advertised. If *a matches scratch/a, for example, that's a bug in the matching code I will have to identify and fix. Yes, this is the case. Based on your reply, the examples I showed are definitely a bug. Thank you so much.
Re: dot gob+extglob bug
On 6/19/14, 6:47 PM, Ian Kelling wrote: The doc says When matching a pathname, the slash character must always be matched explicitly. Shortly thereafter, in the next paragraph of the same section, GLOBIGNORE is described, which does not treat / as special, but this is not mentioned, and is very unexpected to me. Closer inspection, I see same language filenames matching a pattern is used in both paragraphs, so I think some clarification is needed. The GLOBIGNORE matching code treats the patterns and strings to be matched as pathnames, and treats `/' specially (that is, it specifies FNM_PATHNAME to bash's internal version of fnmatch). If *a matches scratch/a, for example, that's a bug in the matching code I will have to identify and fix. None of `*', `?', or bracket expressions should match a slash. And then, another bug or doc clarification. The various [:class:] forms don't seem to work at all in GLOBIGNORE. Yeah, this is a different problem caused by an oversight. The colon in the bracket expression is being treated as a pattern delimiter. I've appended a patch that fixes this problem. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ *** ../bash-4.3-patched/pathexp.c 2014-01-31 09:34:33.0 -0500 --- pathexp.c 2014-06-20 15:33:09.0 -0400 *** *** 539,543 return 0; ! n = skip_to_delim (s, i, :, SD_NOJMP|SD_EXTGLOB); t = substring (s, i, n); --- 539,543 return 0; ! n = skip_to_delim (s, i, :, SD_NOJMP|SD_EXTGLOB|SD_GLOB); t = substring (s, i, n);
Re: dot gob+extglob bug
Chet Ramey chet.ra...@case.edu writes: On 6/9/14, 3:42 PM, Ian Kelling wrote: Yes, it's an interesting question: what exactly does pattern negation include? You can match all filenames beginning with a `.' by using `.' as the first character of the pattern, so should a negated pattern beginning with a `.' match all filenames beginning with a `.' that don't match that particular pattern? The bash-4.3 implementation says yes. (FWIW, ksh93 disagrees.) Yes, now I understand. I agree with this bash 4.3 behavior. As you pointed out, some of my comments about past bash were wrong. Thank you. Now I think I have I have explored properly the latest version and found some problems I did not fully see before: The doc says When matching a pathname, the slash character must always be matched explicitly. Shortly thereafter, in the next paragraph of the same section, GLOBIGNORE is described, which does not treat / as special, but this is not mentioned, and is very unexpected to me. Closer inspection, I see same language filenames matching a pattern is used in both paragraphs, so I think some clarification is needed. # example: / matters to GLOBIGNORE ~/opt/bash (master) $ ./bash --norc bash-4.3$ cd $(mktemp -d) bash-4.3$ touch a bash-4.3$ GLOBIGNORE=a bash-4.3$ echo * * bash-4.3$ echo ./* ./a # another example of the same phenomenon bash-4.3$ GLOBIGNORE='*a' bash-4.3$ echo ./* ./* And then, this definitely seems like a bug: * matches / in GLOGIGNORE, and so does [/], but ? does not match / # example: ? does not match / bash-4.3$ GLOBIGNORE=.?a bash-4.3$ echo ./* ./a # example: ? does match x bash-4.3$ touch .xa bash-4.3$ echo .x* .x* # example: [/] matches / bash-4.3$ GLOBIGNORE=.[/]a bash-4.3$ echo ./* ./.xa And then, another bug or doc clarification. The various [:class:] forms don't seem to work at all in GLOBIGNORE. Side note, I've added to my bashrc: GLOBIGNORE=*/.:*/..
Re: bash signal trap bug
On Sat, 11 Jan 2014, Chet Ramey wrote: There are a few things going on here. First, after the first SIGHUP, you are running the entire script from a trap handler. Bash treats things in a trap handler context a little specially. Second, bash doesn't allow recursive trap invocations: it blocks the signal for which the trap is being run while the trap command is being executed, as if you were running a signal handler. That's why the second SIGHUP has no apparent effect. ok, but let's document it. Anyway - some trap reset would be very good thing. Also, bash doesn't set the flag that a signal is no longer pending until after it executes the trap command. This means that the flag is still set for SIGHUP (signal 1) (because you're running from the trap handler) when the SIGINT (signal 2) arrives and is processed. Bash processes signals in order, and so attempts to execute the trap commands for SIGHUP before SIGINT. That's why SIGINT appears to act like SIGHUP. (This is arguably a bug.) Yes, it is. And it's _very_ confusing... :) I have made several changes to the trap command processing, and things in bash-4.3 should be closer to the way you want them to run. Can you give some patch/link? However, there is enough variation in how different shells handle this situation (bash, ksh93, dash, and zsh all act differently) that there's no consensus on exactly what's right. First of all it has to behave logical. Standarisation is the next step. Anyway - no matter what it the right way few words about the bash way in manual would be very good thing :) -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.
Re: bash signal trap bug
On 1/13/14 4:06 AM, Paweł Gołaszewski wrote: I have made several changes to the trap command processing, and things in bash-4.3 should be closer to the way you want them to run. Can you give some patch/link? The latest round of changes will be out on savannah in a couple of days at most. They will also be part of bash-4.3-rc2, which should be out soon. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash signal trap bug
On Mon, 13 Jan 2014, Chet Ramey wrote: I have made several changes to the trap command processing, and things in bash-4.3 should be closer to the way you want them to run. Can you give some patch/link? The latest round of changes will be out on savannah in a couple of days at most. They will also be part of bash-4.3-rc2, which should be out soon. ok, thanks :) -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.
Re: bash signal trap bug
On 1/8/14, 12:01 PM, Paweł Gołaszewski wrote: Hello, I think I've found bug in signal handling in bash. Look at 2 scripts: http://www.blues.gda.pl/SOURCES/show_logs.sh http://www.blues.gda.pl/SOURCES/show_logs.zsh Both are identical. zsh version works fine, bash version doesn't. After start everything is fine, a can send _one_ HUP signal and it works as expected. The next HUP simply doesn't work. Even more: INT signal (Ctrl+C) works... like SIGHUP. There are a few things going on here. First, after the first SIGHUP, you are running the entire script from a trap handler. Bash treats things in a trap handler context a little specially. Second, bash doesn't allow recursive trap invocations: it blocks the signal for which the trap is being run while the trap command is being executed, as if you were running a signal handler. That's why the second SIGHUP has no apparent effect. Also, bash doesn't set the flag that a signal is no longer pending until after it executes the trap command. This means that the flag is still set for SIGHUP (signal 1) (because you're running from the trap handler) when the SIGINT (signal 2) arrives and is processed. Bash processes signals in order, and so attempts to execute the trap commands for SIGHUP before SIGINT. That's why SIGINT appears to act like SIGHUP. (This is arguably a bug.) I have made several changes to the trap command processing, and things in bash-4.3 should be closer to the way you want them to run. However, there is enough variation in how different shells handle this situation (bash, ksh93, dash, and zsh all act differently) that there's no consensus on exactly what's right. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange re-initialization of array. Bug or feature?
On 11/27/12 7:37 PM, Tim Friske wrote: If sourced at least twice from another script I get the following output printed: AAA BBB declare -A ONCE='()' CCC declare -A ONCE='([std.bash]=1 )' BBB declare -Ai ONCE='()' CCC declare -Ai ONCE='([std.bash]=1 )' If I remove the initialization =() from declare -gAi ONCE I get the following output printed: AAA BBB declare -Ai ONCE='()' CCC declare -Ai ONCE='([std.bash]=1 )' BBB declare -Ai ONCE='([std.bash]=1 )' The declare -gAi ONCE=() seems to get executed every time although surrounded by [[ ! -v ONCE ]] whereas echo AAA within the same if-block only the first time. Is this a bug or feature? This is the same bug I described earlier today, with the same fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Strange re-initialization of array. Bug or feature?
Hi folks,
I execute the following code with Bash version GNU bash, Version
4.2.39(1)-release (x86_64-redhat-linux-gnu) on Fedora 17:
# Returns 0 else 1 if the sourcing (source) script isn't keyed by its base
name in the global ONCE array yet.
#
# A script should include this script near the top with source me_once ||
return 0 in order to get sourced itself only
# once.
#
# @return 0 on success, n != 0 on failure.
#
function me_once {
unset -f me_once
if [[ ! -v ONCE ]]; then
echo AAA
declare -gAi ONCE=()
fi
echo BBB
declare -p ONCE
declare -r a=${BASH_SOURCE[2]##*/}
if (( ${ONCE[$a]:+1} )); then
return 1
else
ONCE+=([$a]=1)
echo CCC
declare -p ONCE
fi
}
me_once
If sourced at least twice from another script I get the following output
printed:
AAA
BBB
declare -A ONCE='()'
CCC
declare -A ONCE='([std.bash]=1 )'
BBB
declare -Ai ONCE='()'
CCC
declare -Ai ONCE='([std.bash]=1 )'
If I remove the initialization =() from declare -gAi ONCE I get the
following output printed:
AAA
BBB
declare -Ai ONCE='()'
CCC
declare -Ai ONCE='([std.bash]=1 )'
BBB
declare -Ai ONCE='([std.bash]=1 )'
The declare -gAi ONCE=() seems to get executed every time although
surrounded by [[ ! -v ONCE ]] whereas echo AAA within the same if-block
only the first time.
Is this a bug or feature?
Cheers,
Tim
--
--
`°
C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Re: excess braces ignored: bug or feature ?
On 02/17/12 20:51, Mike Frysinger wrote:
FOO= BAR=bar
: ${FOO:=${BAR}
echo $FOO
Why should this be a bug? Your second line performs a parameter
expansion, all the remaining characters are joint into the token and
passed to ':'.
No bug.
Re: excess braces ignored: bug or feature ?
On 2/20/12 2:32 AM, Dan Douglas wrote: That one really is ignored. No variable named xxx... is actually set. I assume you mean the first one. It doesn't matter whether or not the variable is set as a side effect of the redirection -- it's in a subshell and disappears. Chet Oh so a subshell is created after all, and that really is a command substitution + redirect! I just chalked it up to Bash recycling the way redirects were parsed. Bash always forks for command substitution. It defers parsing the command between the parens until it's needed, and so doesn't notice that it's only a redirection until it has already forked. It is able to skip the exec and dump the file out directly. I think I ran across that quirk in trying to determine whether $(file) was a special command substitution or it's own kind of expansion but couldn't think of a way to test it. It's a special command substitution (there are others). David has gone to great lengths to avoid forking in ksh93 wherever possible; I assume this is one of those places where he's managed to do so. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: excess braces ignored: bug or feature ?
On 2/20/12 4:17 AM, Dan Douglas wrote: On Sunday, February 19, 2012 04:25:46 PM Chet Ramey wrote: I assume you mean the first one. It doesn't matter whether or not the variable is set as a side effect of the redirection -- it's in a subshell and disappears. Chet Forgot to mention though, It's possible in ksh there is no subshell created if you consider this: The best way to tell for sure is with a system call tracer. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
