Re: [PATCH] fix "Illegal number" on FreeBSD & macOS for x=; echo $((x))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/6/18 2:15 AM, Martijn Dekker wrote:
Op 06-03-18 om 00:23 schreef Harald van Dijk:
On 3/6/18 12:23 AM, Martijn Dekker wrote:
"All variables shall be initialized to zero if they are not otherwise
assigned by the input to the application."

In your example, x has been assigned. Its value is empty, but empty and
unset are two different things.

But I see now that dash gives the same error when x is unset. That part
is definitely wrong for exactly the reason you point out.

By default, all unset variables are considered empty, so they should act
the same.

Except where special behaviour is specified for unset variables, which I believed to be the case here. But see below.

That brings me to another possible issue, though:

$ dash -uc 'unset x; echo $((x))'
0

Shouldn't that give an "parameter not set" error under set -u?
Interestingly, only bash and AT&T ksh93 currently do that.

This is <http://austingroupbugs.net/view.php?id=559>. It's unspecified for now, but will likely become an error in the future.

Also, consensus among existing shells appears to be universal.

Mostly, but not fully. yash is the exception:

   $ yash -c 'unset x; echo $((x))'
   0
   $ yash -c 'x=; echo $((x))'



But in POSIX mode it acts like other shells:

$ yash -o posix -c 'x=; echo $((x))'
0

I stand corrected! Indeed, then it does appear that all shells are in agreement. And when POSIX is (arguably) unclear but all shells are in agreement, the shells' behaviour should generally just be taken as the correct behaviour.

Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux