Re: test -lt inconsistent about white space
I'm more concerned that the error message is misleading; "integer
expression expected" is NOT true; rather an integer LITERAL is expected
(meaning an optional sign followed by one or more digits).
As for fixing the inconsistency, I would rather get rid of whitespace
skipping entirely, perhaps with a shopt to re-enable it.
-Martin
On Sun, 29 Oct 2023 at 05:08, Paul Eggert wrote:
> Consider the following shell script 'doit':
>
> sp=' '
> nl='
> '
> test "${sp}1${sp}" -lt "${sp}2${sp}"
> test "${nl}3${sp}" -lt "${nl}4${sp}"
> test "${sp}5${nl}" -lt "${sp}6${nl}"
> test "${nl}7${nl}" -lt "${nl}8${nl}"
>
> Running the command "bash doit" outputs:
>
> doit: line 6: test: 5
> : integer expression expected
> doit: line 7: test:
> 7
> : integer expression expected
>
> The problem occurs because strtoimax accepts all forms of leading
> whitespace, whereas Bash accepts only space and tab after the integer.
> This is inconsistent: Bash should treat trailing whitespace the same way
> it treats leading whitespace, and should accept all of doit's 'test'
> commands, as Dash does.
>
> Proposed patch attached.
Re: test -lt inconsistent about white space
On Sun, Oct 29, 2023 at 8:49 AM Paul Eggert wrote: > My understanding is that Bash was intended to allow both leading and > trailing whitespace. This is compatible with ksh and with Dash. If > that's the intent, Bash should be consistent about it, just as ksh and > Dash are. There seems little point to allowing one nonempty set of > whitespace characters before the integer, and a different nonempty set > of whitespace characters afterwards. legal_number was isint, which skipped both leading and trailing space using the whitespace macro. See here: https://git.savannah.gnu.org/cgit/bash.git/tree/test.c?id=726f63884db0132f01745f1fb4465e6621088ccf#n354 I think the intented behavior was skipping both leading and trailing horizontal whitespace, which makes sense as a QOL feature, and switching over to strtoimax changed this.
Re: test -lt inconsistent about white space
On 2023-10-29 03:18, Oğuz wrote: I think the intented behavior was skipping both leading and trailing horizontal whitespace, which makes sense as a QOL feature, and switching over to strtoimax changed this. If that's the intent, which is self-consistent but which disagrees with all other shells we know about, then a patch differing from what I submitted should be applied. The patch I sent makes Bash self-consistent in a different way, one that is compatible with ksh and Dash. Although I would vote for the latter on compatibility grounds, the former is at least self-consistent. https://git.savannah.gnu.org/cgit/bash.git/tree/test.c?id=726f63884db0132f01745f1fb4465e6621088ccf#n354 That old code is obviously wrong as it has undefined behavior on integer overflow. So we shouldn't simply revert to it, of course.
