Re: RFC: Enabling or disabling tracing shell functions

[Dan Douglas]

Not sure exactly how zsh does it but I know not having the option for
both global and local tracing can be annoying.

The two big ways of handling xtrace I mostly see are either bash's
global `set -x` or ksh93's per-function tracing, and it can be
annoying to be missing either one. There are tricks for getting the
effect of global xtrace and/or DEBUG traps in ksh, but its lack of a
BASH_XTRACEFD equivalent means it's sometimes impossible to hide the
side-effects of those tricks, so you get messy output.

With regards to `typeset -ft`, I don't like it. DEBUG and RETURN have
totally different usages. Inheriting RETURN very rarely makes sense,
but I almost always want DEBUG inherited because of course it's
primarily used for debugging.

Re: {ref}<&- does not work on array reference subscripts

[Grisha Levit]

I was thinking maybe some {get,set,unbind}_var_or_array_elem functions
would help since there are a number of places that all need to handle this
consistently.  Could catch the case of using subscripts on
array-reference-namerefs in such a function as well.

Re: mapfile creates poorly-named array if passed nameref to array subscript

[Chet Ramey]

On 6/1/16 6:19 PM, Grisha Levit wrote:
> |$ declare -n ref=XXX[0]; mapfile ref <<< $'1\n2'; declare -p XXX[0] declare
> -a XXX[0]=([0]=$'1\n' [1]=$'2\n') |
> 
> maybe makes sense to check for legal identifier before making the array?

Actually, it makes sense to check only for legal identifier instead of
allowing array references for variable creation, sinec they should only
work for variable assignment.

-- 
``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: Mulit-line aliases and PROMPT_COMMAND

[Dan Douglas]

On Thu, Jun 2, 2016 at 7:18 PM, Grisha Levit  wrote:
>
> On Thu, Jun 2, 2016 at 6:57 PM, Chet Ramey  wrote:
>>
>> > Since bash 4.3 multi-line aliases interact very strangely
>>
>> And you're the first person to report them.  I guess there aren't a lot of
>> multi-line aliases out there.
>
>
> I wonder if more crazy use cases will come out of the woodwork when RHEL and
> SUSE finally get 4.3..

I think when they're used in an actual script rather than for
interactive convenience multiline aliases are some of the more useful
ones. The 4.4 changes will make aliases even more interesting.

Re: declare checks on valid nameref names don't account for +=

[Chet Ramey]

On 6/2/16 3:46 AM, Grisha Levit wrote:
> Maybe this is fixed now, but the latest devel went a little overboard :)
> 
> $ declare a=a
> bash: a: nameref variable self references not allowed

Good catch; thanks for the report.

-- 
``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: {ref}<&- does not work on array reference subscripts

[Chet Ramey]

On 6/1/16 6:44 PM, Grisha Levit wrote:
> Yikes, I missed the |exec| command in my example, that would certainly make
> it confusing..
> 
> What I meant was that the assignment works (i.e. the nameref is followed
> correctly), but the relevant code
> 
> doesn’t handle retrieving the value of such a nameref when it needs to do
> so to close the descriptor:

Yes, you're right.  The fix is very similar to part of the fix for the
unset builtin.

-- 
``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: Mulit-line aliases and PROMPT_COMMAND

[Grisha Levit]

On Thu, Jun 2, 2016 at 6:57 PM, Chet Ramey  wrote:

> > Since bash 4.3 multi-line aliases interact very strangely
>
> And you're the first person to report them.  I guess there aren't a lot
> of multi-line aliases out there.
>

I wonder if more crazy use cases will come out of the woodwork when RHEL
and SUSE finally get 4.3..

> All of these will be fixed in bash-4.4.


Thanks for taking a look.

Re: nameref/subscript fixes for unset builtin

[Chet Ramey]

On 5/31/16 11:40 PM, Grisha Levit wrote:
> The patch below addresses the following three issues:

Thanks for the report and patch.  At some point, I might make
`unset -n n[0]' work the same as `unset -n n'.

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: Mulit-line aliases and PROMPT_COMMAND

[Chet Ramey]

On 4/20/16 4:41 PM, Grisha Levit wrote:
> Since bash 4.3 multi-line aliases interact very strangely, especially in 
> connection with PROMPT_COMMAND.

And you're the first person to report them.  I guess there aren't a lot of
multi-line aliases out there.

> 1. PROMPT_COMMAND is executed after every line in the alias, rather than just 
> before the prompt is drawn:
>  
> 2. If PROMPT_COMMAND contains a command substitution (even one that is not 
> executed!) then only the first line of the alias is executed

These two are the same problem.

> 3. If an alias contains a command substitution (this is regardless of 
> PROMPT_COMMAND being set) something really non-sensical happens.

This one actually took some time to track down.  All of these will be fixed
in bash-4.4.

-- 
``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: Please make bash build reproducibly

[Ximin Luo]

CC'ing everyone that was on the previous conversation; Debian's BTS doesn't do 
this automatically :(

We've made some progress on the Debian side; there's a few more stumbling 
blocks though:

On Sat, 28 May 2016 13:38:35 +0200 Reiner Herrmann  wrote:
> Hi,
> 
> it looks like most of the documentation related issues are now solved
> by fixed toolchain packages.  But it still uses the embedded and
> outdated copy of man2html, which doesn't support SOURCE_DATE_EPOCH yet.
> The attached patch uses the system man2html instead of the embedded one.
> 
> After that, the only remaining issue is that the included header file
> /usr/include/bash/config.h varies depending on the kernel version used
> during build [1] (with kernel <4, PGRP_PIPE is defined).
> 

For this particular example, we can just patch this out, i.e. remove it from 
the installed config.h. Debian already forces PGRP_PIPE 1 in config-bot.h, 
which config.h includes at the end.

In general however, installing config.h is a code smell and an anti-pattern - 
it takes test results from the *build machine*, and then forces my machine to 
assume those. The presence of this anti-pattern potentially can make future 
versions unreproducible again, and we'll have to think of new ways to fix 
those, since this PGRP_PIPE forcing is just a lucky coincidence.

The ideal solution from a software architecture viewpoint, would be (1) make 
the headers platform independent and not require a config.h, or if this is 
truly impossible then (2) instead of installing config.h, install some scripts 
to allow the user to generate their own config.h, with their own values. 
However, I don't know how much effort either of these options are. Only a few 
installed headers actually need config.h; perhaps these could be fixed to *not* 
require it:

/usr/include/bash$ grep -r '#include .config.h.'
builtins.h:#include "config.h"
lib/glob/strmatch.h:#include 
shell.h:#include "config.h"
shmbutil.h:#include 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Re: readline doesn't refresh properly anymore

[Dennis Williamson]

On Jun 2, 2016 11:25 AM, "Charles T. Smith" 
wrote:
>
> Hello,
>
> I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't
refresh
> my command line when scrolling through my history - the last tokens are
often
> not shown until I move the cursor there.  Is that due to a change in bash?
>
> TIA,
> cts
I'm guessing that you have non-printing characters in your prompt. I don't
know why the problem wouldn't have shown up for you before though if your
prompt hasn't changed. If this is the problem, you need to surround
sequences of non-printing characters with \[ and \].

Re: readline doesn't refresh properly anymore

[Chet Ramey]

On 4/8/16 11:22 AM, Charles T. Smith wrote:
> Hello,
> 
> I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't refresh
> my command line when scrolling through my history - the last tokens are often
> not shown until I move the cursor there.  Is that due to a change in bash?

There's not enough information to say.  I can't reproduce it, and you're
the only one to report something like this.

-- 
``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: PS1 \# doesn't take into account HISTIGNORE and HISTCONTROL

[Carlos Morata]

Hi,

I think you misunderstod me.
I'm really interested in working with relative command history expasions.
So I need to work with !-$((\#-cmdnumbertarget)), not with !$HISTCMD.

I figure it out pretty well already but I think this is a bug cause you 
loose all the relative history expansions when you hit HISTCONTROL or 
HISTIGNORE and that doesn't get well with the principle of least surprise.


I prefer to enter just "!-3:2" than "!4563:2", cause I think is way more 
intuitive.



Cheers

El 02/06/16 a las 16:34, Chet Ramey escribió:

On 6/2/16 6:38 AM, Carlos Morata wrote:

Hi,

I'm using Fedora 22 and  4.3.42(1)-release.
The issue is that \# prompt variable doesn't take into account the value of
HISTIGNORE and HISTCONTROL.

It's not supposed to.  The `command number' is a count of the commands
entered during the current shell session.  If you want something that
reflects the current position in the history list, use `\!'.  There is
language in the man page that reflects this.

Chet

Re: Bash crash bug

[Chet Ramey]

On 6/2/16 2:25 AM, konsolebox wrote:
> On Thu, Jun 2, 2016 at 1:12 PM, Matthias Zimmerman
>  wrote:
>> a better example is
>> cat <(su) | cat
>> cat <([a very simple program that will block io]) | (any thing else)

$ cat <(sudo cat) | cat
[sudo] password for chet:
^C
$ cat <(sudo cat) | cat
^C
$ echo $BASH_VERSION
4.4.0(20)-rc2

Apparently not, at least not with the current development version.
-- 
``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: a == a[0] convention

[Grisha Levit]

I think all of the stuff here is fixed in the latest devel snapshot, though
there is definitely weirdness if you run the assignments as a typeset
command.  I hadn't even tried the ref4 case, which gives the weirdest
results when used with typeset/declare:
https://groups.google.com/forum/#!topic/gnu.bash.bug/Z-lf3KEnZ34

bash -xc '
typeset -n ref1=a1 ref2=a2 ref3=a3[0] ref4=a4[0]
ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
echo "${ref1} ${ref2[0]} ${ref3} ${ref4[0]}"
typeset -p {ref,a}{1,2,3,4}'
+ typeset -n ref1=a1 ref2=a2 'ref3=a3[0]' 'ref4=a4[0]'
+ ref1=foo
+ ref2[0]=foo
+ ref3=foo
+ ref4[0]=foo
bash: line 2: `a4[0]': not a valid identifier
+ echo 'foo foo foo '
foo foo foo
+ typeset -p ref1 ref2 ref3 ref4 a1 a2 a3 a4
declare -n ref1="a1"
declare -n ref2="a2"
declare -n ref3="a3[0]"
declare -n ref4="a4[0]"
declare -- a1="foo"
declare -a a2=([0]="foo")
declare -a a3=([0]="foo")
bash: line 4: typeset: a4: not found


bash -c 'typeset -n ref[0]=foo'
bash: line 0: typeset: ref[0]: reference variable cannot be an array

Re: suspect nobody noticed these don't work ...

[Greg Wooledge]

On Fri, Apr 08, 2016 at 09:26:47AM -, Charles T. Smith wrote:
> Does anybody know how to use ?(pattern)?  Or @(pattern)?  Or any of them
> except !(pattern)?  If you do an internet search, the man page is always
> blithely quoted, but only !(pattern) is ever demostrated...
> I wonder if the others even work?
> 
>   ?(pattern-list)
>  Matches zero or one occurrence of the given patterns

imadev:~$ cd tmp
imadev:~/tmp$ ls
imadev:~/tmp$ shopt -s extglob
imadev:~/tmp$ touch a.foo b.bar c.gif d.jpg
imadev:~/tmp$ echo a.foo?(zebra)
a.foo

>   *(pattern-list)
>  Matches zero or more occurrences of the given patterns

imadev:~/tmp$ echo a.f*(o)
a.foo

>   +(pattern-list)
>  Matches one or more occurrences of the given patterns

imadev:~/tmp$ echo *.+(gif)
c.gif

>   @(pattern-list)
>  Matches one of the given patterns

imadev:~/tmp$ echo *.@(foo|bar)
a.foo b.bar

>   !(pattern-list)
>  Matches anything except one of the given patterns

imadev:~/tmp$ echo !(*.jpg)
a.foo b.bar c.gif

Re: completion-prefix-display-length doesn't check for common prefix

[Grisha Levit]

Looks like a bunch of stuff posted to the google group just came through.
This is a dupe.

On Wed, Apr 20, 2016 at 5:39 PM, Grisha Levit  wrote:

> f() { COMPREPLY=(aa bb cc); }
> complete -F f f
> bind 'set completion-prefix-display-length 2'
>
> $ f  [TAB][TAB]
> ...aa  ...bb  ...cc
>
> None of the completion entries share a common prefix, though the docs
> suggest that only common prefixes are removed:
>
> The length in characters of the common prefix of a list of possible
> completions
> that  is  displayed without modification.  When set to a value greater
> than zero,
> common prefixes longer than this value are replaced with an ellipsis
> when
> displaying possible completions.
>
>
> colored-completion-prefix has the same issue, in that it colors the first
> n characters, where n is the length of the word being completed.
>
> On a related note, colored-completion-prefix has no effect if
> completion-prefix-display-length is greater than 0.
>

edit-and-execute-command, history and PS1

[Jure Oder]

Dear all,

I have noticed strange behaviour if my PS1 variable contains "the history
number of this command" (\!). When the prompt returns after invoking the
edit-and-execute-command (C-xC-e) the history number is not increased. If I
then press return, the history number is increased by two (or more,
depending on how many lines(?) I entered with the editor). Also, if I then
list the history, I notice that both, the part that was entered in the line
before invoking (C-xC-e) and the part actually executed, are listed in
history. The history number shown in the prompt before invoking C-xC-e
refers to the partially constructed line (or empty, if nothing was
entered). The actual history number I have to use to rerun the command is
one higher.

I assume this is not the intended behaviour.

Steps to reproduce ( marks where the key combination is pressed):
$ env -i /bin/bash --norc --noprofile
bash-4.3$ echo $BASH_VERSION
4.3.42(1)-release
bash-4.3$ EDITOR=vim
bash-4.3$ PS1='\! > '
4 > ls |
ls | grep foo
4 >
6 > history
1  echo $BASH_VERSION
2  EDITOR=vim
3  PS1='\! > '
4  ls |
5  ls | grep foo
6  history
7 >

I get similar behaviour with 4.3.33(2)-release, and 3.2.51(1)-release.

Thank you for your time and your dedication!

Best regards,
Jure

completion-prefix-display-length doesn't check for common prefix

[Grisha Levit]

f() { COMPREPLY=(aa bb cc); }
complete -F f f
bind 'set completion-prefix-display-length 2'

$ f  [TAB][TAB]
...aa  ...bb  ...cc

None of the completion entries share a common prefix, though the docs suggest 
that only common prefixes are removed:

The length in characters of the common prefix of a list of possible 
completions
that  is  displayed without modification.  When set to a value greater than 
zero,
common prefixes longer than this value are replaced with an ellipsis when 
displaying possible completions.


colored-completion-prefix has the same issue, in that it colors the first n 
characters, where n is the length of the word being completed.

On a related note, colored-completion-prefix has no effect if 
completion-prefix-display-length is greater than 0.

Mulit-line aliases and PROMPT_COMMAND

[Grisha Levit]

Since bash 4.3 multi-line aliases interact very strangely, especially in 
connection with PROMPT_COMMAND.

1. PROMPT_COMMAND is executed after every line in the alias, rather than just 
before the prompt is drawn:

alias a=$'echo 1\necho2'
PROMPT_COMMAND='echo $HOSTNAME'

$ a
1
home
2
home
$ 

2. If PROMPT_COMMAND contains a command substitution (even one that is not 
executed!) then only the first line of the alias is executed

alias a=$'echo 1\necho2'
PROMPT_COMMAND='echo ${HOSTNAME-$(hostname)}'

$ a
1
home
$ 

3. If an alias contains a command substitution (this is regardless of 
PROMPT_COMMAND being set) something really non-sensical happens.

alias a=$'echo 1 $(id)\necho 2'

$ a
1 2 id
$ 

For the end user, replacing any multi-line aliases with ';' delimited ones 
should probably work just fine.  I can't think of any use-cases where the 
behavior of one style would be different from another so maybe multi-line 
aliases should be disallowed.

itrace() in jobs.c set_maxchild() w/o -DDEBUG

[Grisha Levit]

diff --git a/jobs.c b/jobs.c
index b6c2506..c612b3a 100644
--- a/jobs.c
+++ b/jobs.c
@@ -4678,9 +4678,9 @@ set_maxchild (nchild)
  int nchild;
 {
   static int lmaxchild = -1;
-
+#ifdef DEBUG
 itrace("set_maxchild (%d)", nchild);
-
+#endif
   if (lmaxchild < 0)
 lmaxchild = getmaxchild ();
   if (lmaxchild < 0)

suspect nobody noticed these don't work ...

[Charles T. Smith]

Does anybody know how to use ?(pattern)?  Or @(pattern)?  Or any of them
except !(pattern)?  If you do an internet search, the man page is always
blithely quoted, but only !(pattern) is ever demostrated...
I wonder if the others even work?

  ?(pattern-list)
 Matches zero or one occurrence of the given patterns
  *(pattern-list)
 Matches zero or more occurrences of the given patterns
  +(pattern-list)
 Matches one or more occurrences of the given patterns
  @(pattern-list)
 Matches one of the given patterns
  !(pattern-list)
 Matches anything except one of the given patterns


$ ls -d ?(*clean*|vim)
ciho-clean  clean  vim

(not that I can think of an application - purely academic)

readline doesn't refresh properly anymore

[Charles T. Smith]

Hello,

I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't refresh
my command line when scrolling through my history - the last tokens are often
not shown until I move the cursor there.  Is that due to a change in bash?

TIA,
cts

Re: PS1 \# doesn't take into account HISTIGNORE and HISTCONTROL

[Chet Ramey]

On 6/2/16 6:38 AM, Carlos Morata wrote:
> Hi,
> 
> I'm using Fedora 22 and  4.3.42(1)-release.
> The issue is that \# prompt variable doesn't take into account the value of
> HISTIGNORE and HISTCONTROL.

It's not supposed to.  The `command number' is a count of the commands
entered during the current shell session.  If you want something that
reflects the current position in the history list, use `\!'.  There is
language in the man page that reflects this.

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/

RFC: Enabling or disabling tracing shell functions

[Paulo César Pereira de Andrade]

  Hi,

  This is a "RFC" to update documentation to better match behavior,
or, to get some information about shell tracing.

  Bellow I am quoting a request from an user:

---8<---
The bash shell offers the xtrace (set -x), functrace (set -T) and
function trace (typeset -ft) facilities to control script and function
tracing yet it appears that only set -x is effective, tracing the
calling script + any and all called functions.

set -x:
Caller and all functions traced, irrespective of typeset [-+]ft and set [-+]T

set +x:
No trace at all, irrespective of trace -ft and set [-+]T

In contrast, using the POSIX shell (HP-UX), the trace directives "set
[-+]x" and "typeset [-+]ft " interact as follows (regardless of
whether shell functions are defined with the "function name" or
"name()" forms):

set -x:
- typeset -ft name ...
Caller and named function(s) traced

- typeset +ft name ...
Caller but trace from named function(s) suppressed

set +x:
- typeset -ft name ...
Only named function(s) traced

- typeset +ft name ...
No trace at all

So function trace can be governed _independently_ of the calling
script/session trace, which is useful in controlling the amount of
trace generated.  Can bash replicate this behaviour, i.e. trace a
script but NOT its called functions ?
---8<---

  Since access to HP-UX sh, that should be a superset of ksh88 is not easy,
one shell that appears to be very close to the HP-UX sh in this respect is
zsh, that allows either tracing or not tracing only functions.

  Looking at bash source code, it could require a significant change to offer
such feature. First, I believe trace_p() would need to be converted to a three
state, to know all the conditions, or, it could by default trace
functions always
and only not trace if trace_p() is unset. The problem is that trace_p() for
functions is already being used for a different state control.

  Assuming the current trace_p() usage were modified, to implement disable
of traced functions, a pseudo-patch could be:

---8<---
make_cmd.c:make_function_def()
-  temp->flags = 0;
+  temp->flags = att_trace;
---8<---

and
---8<---
execute_cmd.c:execute_function()
   restore_default_signal (ERROR_TRAP);
 }

+  if (echo_command_at_execute && !trace_p (var))
+{
+  unwind_protect_int (echo_command_at_execute);
+  echo_command_at_execute = 0;
+}
+
+
   /* Shell functions inherit the RETURN trap if function tracing is on
  globally or on individually for this function. */
---8<---

but to trace only functions under "set +x" a different approach would be
required (the need for a three-state).

  Attached is a test script from the user, that will work with bash and
zsh (to test ksh behavior need to comment the "set +-T").

Thanks,
Paulo


x.sh
Description: Bourne shell script

PS1 \# doesn't take into account HISTIGNORE and HISTCONTROL

[Carlos Morata]

Hi,

I'm using Fedora 22 and  4.3.42(1)-release.
The issue is that \# prompt variable doesn't take into account the value 
of HISTIGNORE and HISTCONTROL.


Steps to reproduce (* when wrong)
==
$bash --norc
bash-4.3$ PS1="C:\#>"
C:2>HISTIGNORE="history *"
C:3>HISTCONTROL=ignoredups
C:4>echo 4
4
C:5>history 4
   87  PS1="C:\#>"
   88  HISTIGNORE="history *"
   89  HISTCONTROL=ignoredups
   90  echo 4
*C:6>echo !-5:0
echo older command
older command
C:7>repeat
bash: repeat: no se encontró la orden
C:8>repeat
bash: repeat: no se encontró la orden
C:9>repeat
bash: repeat: no se encontró la orden
C:10>echo !-1:0
echo repeat
repeat
*C:11>echo !-2:0
echo echo
echo
==

I don't know if it is intented or a bug. I solved it with few lines of 
bash and show my own command number than \# on PS1.



Cheers

declare ref[x] segfault and garbage values

[Grisha Levit]

These are maybe similar to the less-interesting issue of namerefs pointing
to array subscripts, but are triggered by relatively normal assignments:
--

This one is really strange:

declare -n re=xxdeclare re[4]=78901234567890123456789012echo ${!re*}

Segmentation fault: 11

The assignment expression can use different subscripts/values, but the
total length has to be at least 32 bytes to trigger the segfault.

The last command can also be unset xx, unset re, or anything that uses the
full variable list like export, readonly : ${!foo*}, etc
--

Assignments longer than 16 bytes just don’t work:

declare -n re=xxdeclare re[4]=7890123456declare -p xx

declare -a xx=()

--

Some random memory(?) is assigned to a variable in this pathological case:

declare -n re=xx[0]declare re[45678901234]=declare -p xx

declare -a xx=([0]=$'\260\213@\342\365\177')

​

Re: declare checks on valid nameref names don't account for +=

[Grisha Levit]

Maybe this is fixed now, but the latest devel went a little overboard :)

$ declare a=a
bash: a: nameref variable self references not allowed

On Wed, Jun 1, 2016 at 9:45 AM, Chet Ramey  wrote:

> On 5/31/16 2:08 PM, Grisha Levit wrote:
> > On Wed, May 25, 2016 at 3:29 PM, Chet Ramey  > > wrote:
> >
> >
> > Thanks for the report.  Both of these cases should be caught
> >
> > Is it deliberate that with the latest changes a faulty += RHS causes an
> > existing valid nameref to be unset?
>
> The code has always done that.  With more error checking happening at
> assignment time instead of on reference, it's more apparent.  I'm working
> on it.
>
> > |$ declare -n ref=re $ declare -n ref+=f bash: ref: nameref variable self
> > references not allowed $ declare -p ref bash: declare: ref: not found $
> > declare -n ref=X $ declare -n ref+=/ bash: declare: `/': not a valid
> > identifier $ *declare* -p ref bash: declare: ref: not found|
> >
> > Also, this still seems to miss some stuff that would normally be caught:
> >
> > |$ declare -n ref=ref[0] bash: declare: ref: nameref variable self
> > references not allowed $ declare -n ref=re ref+=f[0] $ declare -p ref
> > declare -n ref="ref[0]" |
>
> Yes, though you still can't use it.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>

a == a[0] convention

[Dan Douglas]

This is possibly relevant to some of Grisha's observations. First,
declaring or assigning to a variable with a subscript. I think I would
prefer these to be errors for various reasons. Admittedly there's an
argument for making one or both of these non-errors for declarations
without assignment for consistency with the current documentation, and
maybe even allowing the current behavior (no errors ever). I think
that leads to confusion though.

 $ bash -c 'typeset -n ref[0]=foo' # no error
 $ bash -c 'typeset -n ref[1]=foo' # no error

The other variations on this theme are if there are references to
"arrays" with or without a zero subscript. Bash example:

 $ bash -xc '
typeset -n ref1=a1 ref2=a2 ref3=a3[0] ref4=a4[0]
ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
echo "${ref1} ${ref2[0]} ${ref3} ${ref4[0]}"
typeset -p {ref,a}{1,2,3,4}'

+ typeset -n ref1=a1 ref2=a2 'ref3=a3[0]' 'ref4=a4[0]'
+ ref1=foo
+ ref2[0]=foo
+ ref3=foo
+ ref4[0]=foo
+ echo 'foo foo foo foo'
foo foo foo foo
+ typeset -p ref1 ref2 ref3 ref4 a1 a2 a3 a4
declare -n ref1="a1"
declare -a ref2=([0]="foo")
declare -n ref3="a3[0]"
declare -a ref4=([0]="foo")
declare -- a1="foo"
/home/ormaaj/doc/programs/bash-build/bash: line 4: typeset: a2: not found
declare -a a3=([0]="foo")
/home/ormaaj/doc/programs/bash-build/bash: line 4: typeset: a4: not found

I think the mksh result for that code is most like what bash is
probably going for. It mostly treats `ref[0]` as `ref` both when
assigning and dereferencing.

 $ mksh -xc '
typeset -n ref1=a1 ref2=a2 ref3=a3[0] ref4=a4[0]
ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
echo "${ref1} ${ref2[0]} ${ref3} ${ref4[0]}"
typeset -p {ref,a}{1,2,3,4}'
+ typeset -n 'ref1=a1' 'ref2=a2' 'ref3=a3[0]' 'ref4=a4[0]'
+ ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
+ echo 'foo foo foo foo'
foo foo foo foo
+ typeset -p ref1 ref2 ref3 ref4 a1 a2 a3 a4
typeset -n ref1=a1
typeset -n ref2=a2
typeset -n ref3='a3[0]'
typeset -n ref4='a4[0]'
typeset a1=foo
set -A a2
typeset a2[0]=foo
set -A a3
typeset a3[0]=foo
set -A a4
typeset a4[0]=foo

ksh93 also does that except ref4 which understandably assigns to a4[0][0].

Re: Bash crash bug

[konsolebox]

On Thu, Jun 2, 2016 at 1:12 PM, Matthias Zimmerman
 wrote:
> a better example is
> cat <(su) | cat
> cat <([a very simple program that will block io]) | (any thing else)

Ok, it does crash.

Next time, please send your message to bug-bash@gnu.org as well.

-- 
konsolebox