Re: Indirect expansion and arrays

[Greg Wooledge]

On Thu, Jul 29, 2010 at 10:55:51PM +0200, Bernd Eggink wrote:
> It seems that indirect expansion doesn't work with arrays:

ksh93 has a feature called nameref:

myfunc() {
   nameref ref=$1
   echo "array $1 has ${#ref[*]} elements"
}

I wouldn't mind seeing this in bash, though I'm not going to attempt
to code it.

inconsistent exit status of ((count++))

[Andrew Benton]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux eccles 2.6.35-rc6 #1 SMP Fri Jul 23 11:52:29 BST 
2010 x86_64 x86_64 x86_64 GNU/Linux

Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.1
Patch Level: 2
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]

If I use set -e to make my scripts exit on error, the scripts fail if I 
use something like:


count=0
((count++))

Repeat-By:

andy:~$ count=0
andy:~$ ((count++))
andy:~$ echo $?
1
andy:~$ ((count++))
andy:~$ echo $?
0

Fix:

This isn't a fix but I can work around this bug if I use ((++count))

andy:~$ count=0
andy:~$ ((++count))
andy:~$ echo $?
0
andy:~$

bash(1): please fix a few typos and some style stuff

[David Prévot]

Package: bash
Version: 4.1-3
Severity: wishlist
Tags: patch upstream

Hi Chet, Matthias,

While updating the French translation of Bash manual pages (for the
manpages-fr-extra package), I spotted a few typos and other style stuff.
Please find attached a patch against the version shipped in the source
package also available online [1] (bash-manpage.patch) and a patch
against the version shipped in the binary debian package
(bash-manpage-debian.patch with a pair of added modifications).

[1] ftp://ftp.cwru.edu/pub/bash/bash.1.gz

Please also consider modifying unsupported by po4a alternative stuff like:

> .if t \fB|  &  ;  (  )  <  >  space  tab\fP
> .if n \fB|  & ; ( ) < > space tab\fP

around line 470 to something equivalent like:

> .if t .ss 24
> \fB|  & ; ( ) < > space tab\fP
> .if t .ss 12

The same remark applies for the copyright around line 50 and some other
stuff along the document. I'm willing to try and help on this stuff if
you are to consider it. Note that we will be glad if you decided to
sheep directly the French translation of manual pages upstream.

Cheers

David

--- bash.1	2010-07-29 15:42:42.0 -0400
+++ bash-orig.1	2010-07-29 15:34:02.0 -0400
@@ -410,7 +410,7 @@
 .PP
 .B Bash
 attempts to determine when it is being run with its standard input
-connected to a a network connection, as if by the remote shell
+connected to a network connection, as by the remote shell
 daemon, usually \fIrshd\fP, or the secure shell daemon \fIsshd\fP.
 If
 .B bash
@@ -929,7 +929,7 @@
 below).
 The file descriptors can be utilized as arguments to shell commands
 and redirections using standard word expansions.
-The process id of the shell spawned to execute the coprocess is
+The process ID of the shell spawned to execute the coprocess is
 available as the value of the variable \fINAME\fP_PID.
 The \fBwait\fP
 builtin command may be used to wait for the coprocess to terminate.
@@ -1192,7 +1192,7 @@
 In the context where an assignment statement is assigning a value
 to a shell variable or array index, the += operator can be used to
 append to or add to the variable's previous value.
-When += is applied to a variable for which the integer attribute has been
+When += is applied to a variable for which the \fIinteger\fP attribute has been
 set, \fIvalue\fP is evaluated as an arithmetic expression and added to the
 variable's current value, which is also evaluated.
 When += is applied to an array variable using compound assignment (see
@@ -1352,13 +1352,13 @@
 This variable is read-only.
 .TP
 .B BASHPID
-Expands to the process id of the current \fBbash\fP process.
+Expands to the process ID of the current \fBbash\fP process.
 This differs from \fB$$\fP under certain circumstances, such as subshells
 that do not require \fBbash\fP to be re-initialized.
 .TP
 .B BASH_ALIASES
 An associative array variable whose members correspond to the internal
-list of aliases as maintained by the \fBalias\fP builtin
+list of aliases as maintained by the \fBalias\fP builtin.
 Elements added to this array appear in the alias list; unsetting array
 elements cause aliases to be removed from the alias list.
 .TP
@@ -1814,7 +1814,7 @@
 with value
 .if t \f(CWt\fP,
 .if n "t",
-it assumes that the shell is running in an emacs shell buffer and disables
+it assumes that the shell is running in an Emacs shell buffer and disables
 line editing.
 .TP
 .B FCEDIT
@@ -2219,8 +2219,8 @@
 not arrive.
 .TP
 .B TMPDIR
-If set, \fBBash\fP uses its value as the name of a directory in which
-\fBBash\fP creates temporary files for the shell's use.
+If set, \fBbash\fP uses its value as the name of a directory in which
+\fBbash\fP creates temporary files for the shell's use.
 .TP
 .B auto_resume
 This variable controls how the shell interacts with the user and
@@ -2595,7 +2595,7 @@
 expanded and that value is used in the rest of the substitution, rather
 than the value of \fIparameter\fP itself.
 This is known as \fIindirect expansion\fP.
-The exceptions to this are the expansions of ${!\fIprefix\fP*} and
+The exceptions to this are the expansions of ${\fB!\fP\fIprefix\fP\fB*\fP} and
 ${\fb!\fp\finame\fp[...@\fp]} described below.
 The exclamation point must immediately follow the left brace in order to
 introduce indirection.
@@ -2655,7 +2655,7 @@
 .TP
 ${\fIparameter\fP\fB:\fP\fIoffset\fP\fB:\fP\fIlength\fP}
 .PD
-\fBSubstring Expansion.\fP
+\fBSubstring Expansion\fP.
 Expands to up to \fIlength\fP characters of \fIparameter\fP
 starting at the character specified by \fIoffset\fP.
 If \fIlength\fP is omitted, expands to the substring of
@@ -2689,7 +2689,7 @@
 .TP
 ${\fb!\fp\fiprefix\fp...@\fp}
 .PD
-\fBNames matching prefix.\fP
+\fBNames matching prefix\fP.
 Expands to the names of variables whose names begin with \fIprefix\fP,
 separated by the first character of the
 .SM
@@ -2703,7 +2703,7 @@
 .TP
 ${\fB!\fP\fIname\fP[\fI*\fP]}
 .PD
-\fBList of array keys.\fP
+\fBList of array keys\fP.
 If \fIname\fP is an array variable, expands to t

Re: inconsistent exit status of ((count++))

[Stefano Lattarini]

At Thursday 29 July 2010, Andrew Benton wrote:
> 
> andy:~$ count=0
> andy:~$ ((count++))
> andy:~$ echo $?
> 1
> andy:~$ ((count++))
> andy:~$ echo $?
> 0
I don't think it's a bug, it's just an effect of:
  1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates
 to zero, and
  2. `var++' being a *post-increment* (i.e. the increment of `var'
 takes place after its previous value has been substituted in
 the expression).

You can verify this with:
  $ i=0
  $ echo $((i++))
  0
  $ echo $i
  1
  $ echo $((++i))
  2
  $ echo $i
  2

> 
> Fix:
> 
> This isn't a fix but I can work around this bug if I use
> ((++count))
Yes, because here `count' is incremented before its value is 
substituted into the expression.

> 
> andy:~$ count=0
> andy:~$ ((++count))
> andy:~$ echo $?
> 0
> andy:~$

HTH,
   Stefano

Re: inconsistent exit status of ((count++))

[Andrew Benton]

On 30/07/10 19:55, Stefano Lattarini wrote:

At Thursday 29 July 2010, Andrew Benton wrote:


andy:~$ count=0
andy:~$ ((count++))
andy:~$ echo $?
1
andy:~$ ((count++))
andy:~$ echo $?
0

I don't think it's a bug, it's just an effect of:
   1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates
  to zero, and
That makes no sense to me. Why would evaluating an expression have a 
non-zero exit status if there was no error? That makes the exit status 
no use at all for evaluating whether an error has occurred. How can I 
check for errors if I can't rely on the exit status? How can that not be 
a bug?


Andy

Re: inconsistent exit status of ((count++))

[Stefano Lattarini]

At Friday 30 July 2010, Andrew Benton wrote:
> On 30/07/10 19:55, Stefano Lattarini wrote:
> > At Thursday 29 July 2010, Andrew Benton wrote:
> >> andy:~$ count=0
> >> andy:~$ ((count++))
> >> andy:~$ echo $?
> >> 1
> >> andy:~$ ((count++))
> >> andy:~$ echo $?
> >> 0
> > 
> > I don't think it's a bug, it's just an effect of:
> >1. `((EXPR))' returning a non-zero exit status iff EXPR
> >evaluates to zero, and
BTW, this behaviour is documented here, in the entry `((...))':

 
> That makes no sense to me. Why would evaluating an expression have
> a non-zero exit status if there was no error?
It can be very useful for use in conditional or looping constructs, e.g.:

  if ((verbosity > 1)); then
echo "blah blah..."
  fi

Also, non-zero exit status does not necessary indicate a true error in
the Unix world (the `grep' utility is a noteworthy and outstanding
example).

> That makes the exit status no use at all for evaluating whether an
> error has occurred.
> How can I check for errors if I can't rely on the exit status? How
> can that not be a bug?
>
It's somewhat of a trade-off; and I hope that my explanation makes it
clear that it's a good tradeoff.

But then, maybe an exit status of `2' instead of `1' in case of errors
in ((...)) would be helpful -- currently the exit status is still `1'
also if a real error is present:

  $ ((1+)); echo \$?=$?
  bash: ((: 1+: syntax error: operand expected (error token is "+")
  $?=1

Regards,
  Stefano

Re: inconsistent exit status of ((count++))

[Greg Wooledge]

On Fri, Jul 30, 2010 at 07:33:00PM +0100, Andrew Benton wrote:
> On 30/07/10 19:55, Stefano Lattarini wrote:
> >I don't think it's a bug, it's just an effect of:
> >   1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates
> >  to zero, and

> That makes no sense to me. Why would evaluating an expression have a 
> non-zero exit status if there was no error?

The ((...)) command is used like this:

  if ((a < b)); then
stuff
  fi

So it returns an exit status -- true or false -- depending on whether the
arithmetic expression inside it is true or false.

The syntax and semantics of the arithmetic expression are almost identical
to what's used in C.  Any expression in there has a value.  Equations or
inequalities are special cases, but just like in C, plain ol' integers
have "true" and "false" values as well:

imadev:~$ ((42)); echo $?
0
imadev:~$ ((0)); echo $?
1

There is no real concept of an "error" in an arithmetic context.  The
exit status of an arithmetic command (either ((...)) or let) is simply
determined by the value of the expression inside it.

imadev:~$ let a=5/2; echo $?
0
imadev:~$ let a=0/2; echo $?
1

In fact, the only way you CAN generate an error in an arithmetic context
is to divide by zero:

imadev:~$ let a=2/0; echo $?
bash: let: a=2/0: division by 0 (error token is "0")
1

But that is such a rare case, and so completely preventable, that there's
just no provision to distinguish it from the case where an expression
evaluates to zero.

Re: inconsistent exit status of ((count++))

[Greg Wooledge]

On Fri, Jul 30, 2010 at 09:49:22PM +0200, Stefano Lattarini wrote:
> But then, maybe an exit status of `2' instead of `1' in case of errors
> in ((...)) would be helpful -- currently the exit status is still `1'
> also if a real error is present:
> 
>   $ ((1+)); echo \$?=$?
>   bash: ((: 1+: syntax error: operand expected (error token is "+")
>   $?=1

Most syntax errors cause the shell to abort right then and there, when in
non-interactive mode.  Syntax errors inside an arithmetic context don't,
which is already weird.  If I were going to ask for a change, it would
be to make them crash the script instead of letting bash continue.

Re: inconsistent exit status of ((count++))

[Stefano Lattarini]

At Friday 30 July 2010, Greg Wooledge wrote:
> On Fri, Jul 30, 2010 at 09:49:22PM +0200, Stefano Lattarini wrote:
> > But then, maybe an exit status of `2' instead of `1' in case of
> > errors in ((...)) would be helpful -- currently the exit status
> > is still `1'
> > 
> > also if a real error is present:
> >   $ ((1+)); echo \$?=$?
> >   bash: ((: 1+: syntax error: operand expected (error token is
> >   "+") $?=1
> 
> Most syntax errors cause the shell to abort right then and there,
> when in non-interactive mode.  Syntax errors inside an arithmetic
> context don't, which is already weird.  If I were going to ask for
> a change,
Well, I wasn't really advocating a change here, since I've never had
problems with the current behaviour; I was just pointing out that
it is suboptimal.

> it would be to make them crash the script instead of
> letting bash continue.
This makes sense; now I think that, if there's going to be a change, 
it should be on the lines proposed by you.

Regards,
  Stefano