Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Inian Vasanth <inian.vasanth@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: behavior of arithmetic evaluation operator inside extended test operator
Date: Tue, 19 May 2020 23:04:34 +0530
Lines: 115
Approved: bug-bash@gnu.org
Message-ID: <mailman.578.1589909689.3227.bug-bash@gnu.org>
References: <CADNZbLQ8p9ggi3pzwY1LKk=O2T4_a9W2Awap3bXSzGQxhNN=uQ@mail.gmail.com> <20200519141033.GU751@eeg.ccf.org> <CADNZbLT2Fid=AMyJRPeXifnGKkTX0EcUJRuOcr8radY-jTHcuA@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
To: bug-bash@gnu.org, wooledg@eeg.ccf.org
Envelope-to: bug-bash@gnu.org
In-Reply-To: <20200519141033.GU751@eeg.ccf.org>
Received-SPF: pass client-ip=2607:f8b0:4864:20::a2e; envelope-from=inian.vasanth@gmail.com; helo=mail-vk1-xa2e.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <CADNZbLT2Fid=AMyJRPeXifnGKkTX0EcUJRuOcr8radY-jTHcuA@mail.gmail.com>
X-Mailman-Original-References: <CADNZbLQ8p9ggi3pzwY1LKk=O2T4_a9W2Awap3bXSzGQxhNN=uQ@mail.gmail.com> <20200519141033.GU751@eeg.ccf.org>
Xref: csiph.com gnu.bash.bug:16301

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.

On Tue, May 19, 2020 at 7:40 PM Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> On Tue, May 19, 2020 at 06:10:30PM +0530, Inian Vasanth wrote:
> > The behavior of arithmetic context operator $((..)) inside [[..]] is not
> so
> > well defined.
>
> It's simply a substitution.  The $(( )) is evaluated, and the result
> is placed into the [[ ]] command as a word.
>
> > The downside is the operator
> > without $ when used as ((..)) just behaves as double grouping,
>
> Correct, as you demonstrated below.
>
> > but $((..))
> > behaves as a valid arithmetic evaluation followed by non empty string
> > comparison `-n`
>
> Well, yes.  What did you *expect*?  What are you trying to do?
>
> > bash -cx '[[ (( 100 < 3 )) ]] && echo ok'
> > + bash -cx '[[ (( 100 < 3 )) ]] && echo ok'
> > + [[ 100 < 3 ]]
> > + echo ok
>
> The parentheses here are doubly redundant.  You're performing a grouping,
> but there is only one operator, so there's nothing to group *for*.  And
> you're doing the grouping twice, for no discernable reason.
>
> You're also using the < operator in a [[ ]] command, which is string
> comparison, not integer comparison.
>
> If your goal was simply "check whether the integer 100 is less than the
> integer 3", you don't need to use the [[ ]] command at all.
>
> if ((100 < 3)); then
>   echo ok
> else
>   echo not ok
> fi
>
> If you insist on using [[ ]] for some reason, integer comparisons can be
> forced with the -lt -gt (et al.) operators.
>
> if [[ 100 -lt 3 ]]; then
> ...
>
> > bash -cx '[[ $(( 100 < 3 )) ]] && echo ok'
> > + bash -cx '[[ $(( 100 < 3 )) ]] && echo ok'
> > + [[ -n 0 ]]
> > + echo ok
> > ok
>
> Here, you are forcing an arithmetic substitution to be explicitly
> performed,
> before the [[ ]] command begins.  The result of the arithmetic substitution
> is a word, and that word will be checked for non-zero-length by the [[
> command.  It is exactly as if you had written:
>
> tmp=$((100 < 3))
> [[ $tmp ]] && ...
>
> The form [[ $x ]] is just the same as [[ -n $x ]] and that's what you
> have written here.
>
>
> > bash -cx '[[ $(( 100 < 300 )) ]] && echo ok'
> > + bash -cx '[[ $(( 100 < 300 )) ]] && echo ok'
> > + [[ -n 1 ]]
> > + echo ok
> > ok
>
> Same.  It doesn't matter whether the result of the arithmetic expression
> is 1 (true) or 0 (false), because both of these words are strings of
> non-zero length.
>
> To repeat: if your goal is to compare integers, you should use one of
> these forms:
>
> if ((x < y)); then ...
>
> if [[ $x -lt $y ]]; then ...
>
> if test "$x" -lt "$y"; then ...
>
> if [ "$x" -lt "$y" ]; then ...
>
>
> Remember, the [ and [[ commands are just that: *commands*.  They are not
> a part of the "if" syntax.  You don't *need* them every time you use
> an "if".  You don't need to bend over backwards trying to work out how
> to merge the command you actually want to use, together with the [[
> command.
>
> Just omit the [[ if it's not the command you want.
>


-- 
Regards,
INIAN VASANTH P