Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16303

Re: behavior of arithmetic evaluation operator inside extended test operator

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On 5/19/20 1:34 PM, Inian Vasanth wrote:
> Thanks Greg for the explanation. Yes your explanation  aligns with my
> understanding too.
> 
> My recommendation was to check if this behavior needs to be documented as a
> side-note in this section of
> http://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Bash-Conditional-Expressions
> to
> explain that, any other primaries other than the ones mentioned above will
> be evaluated as a literal string result. I also tried finding an
> explanation in your wiki at
> https://mywiki.wooledge.org/BashGuide/TestsAndConditionals, but there
> wasn't an explicit point made.

The constructs:

(list)
{ list; }
[[ expression ]]
(( expression ))
for name [ [ in [ word ... ] ] ; ] do list ; done
for (( expr1 ; expr2 ; expr3 )) ; do list ; done
select name [ in word ] ; do list ; done
case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac
if list; then list; [ elif list; then list; ] ... [ else list; ] fi
while list-1; do list-2; done
until list-1; do list-2; done

are listed as *competing* definitions of "what is a compound command".

I don't see anywhere in the definition of "CONDITIONAL EXPRESSIONS" that
states you may use completely arbitrary compound commands as the
expression within a [[ compound command. It seems to me that
"CONDITIONAL EXPRESSIONS" is pretty unambiguously explicit on what
constitutes one.

Any possible reading which even implies that

(( expression ))

is valid when nested inside of

[[ expression ]]

as

[[ (( expression )) ]]

must also imply that one can do

[[ [[ expression ]] ]]

or [[ for i in one two three; do cmd; done ]]


So I'm completely baffled why this might need further clarification.

As for your claim that

[[ $(( 100 < 3 )) ]]

is doing "undocumented arithmetic evaluation",

> Word splitting and pathname expansion are not performed on the words
> between the [[ and ]]; tilde expansion, parameter and variable
> expansion, arithmetic expansion, command substitution, process
> substitution, and quote removal are performed.

And as duly noted in the documentation, $(( 100 < 3 )) is Arithmetic
Expansion and is being performed on the words inside the [[ and ]].

> explain that, any other primaries other than the ones mentioned above
> will be evaluated as a literal string result

The documentation *already* states that. Nothing is valid in a
conditional expression other than the listed primaries, *but* one of
those documented primaries is `[[ string ]]` which is defined to be a
primary identical to `[[ -n string ]]`. Only strings are valid for this
primary, no exceptions. Other primaries don't even accept strings at
all, they accept filenames; filenames just so happen to be a subcategory
of strings. The same can be said of the -t primary, which accepts a file
descriptor number, which is a subcategory of integers, not strings (you
may then argue that an integer is a subcategory of a string), or various
primaries which operate on variable names, which are subcategories of
strings, etc. etc.


The documentation doesn't need changing. People need to realize when
they read the documentation that a conditional expression happens after
other stages of the shell execution process, and that their
understanding of conditional expressions is incomplete if they don't
understand where they are permitted to use them and how to use tilde
expansion, parameter and variable expansion, arithmetic expansion,
command substitution, process substitution, and quote removal in order
to preprocess words to then use in a conditional expression.

To improve their understanding, they must therefore read the definition
of the [[ ]] syntax. Thus, enlightenment shall be obtained.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: behavior of arithmetic evaluation operator inside extended test operator Eli Schwartz <eschwartz@archlinux.org> - 2020-05-19 14:36 -0400

csiph-web