Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: =?UTF-8?B?T8SfdXo=?= Newsgroups: gnu.bash.bug Subject: Re: behavior of arithmetic evaluation operator inside extended test operator Date: Tue, 19 May 2020 21:05:25 +0300 Lines: 148 Approved: bug-bash@gnu.org Message-ID: References: <20200519141033.GU751@eeg.ccf.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1589911541 21962 209.51.188.17 (19 May 2020 18:05:41 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org, wooledg@eeg.ccf.org To: Inian Vasanth Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JuS5CrCxEIll1hA/DBoWbeITSnA3cOvnLjAQSc1WBBA=; b=lVpuG6MRmmy3XItHlA662dSnpsdCc6Is/cqDNrKDcTX3jLBS4r+K/HZcQ1KiF00F/s 9NpuigMOgGnPHhO5c8zcV/0thqzAA0iTOEAGAXpFRUH/gGMjWbZ5O0k9fu7m/dCedRaW MHjNq9fNlHfJNFhOVCbNGJ/4uBKrvYZZFzkaMovq1f+c/RrCovGeN3geVndIS+fNU5WM X+fke0AMdY1AG5Q14nlh/KL9leMui8EBVXHtbM848g1E7yliCiEmhgmT9P0W2KJAMnhK Q8mBE9f+H+4OdCpkAzYn4RESC4+9OtdZycxJhXhWxtsHECtU6fUId78oJpw57XX9daWz 8ChQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JuS5CrCxEIll1hA/DBoWbeITSnA3cOvnLjAQSc1WBBA=; b=ldUblYU8SoYvd/j6miAXxeS2CEKYsMEwyVDe/yMVE+9vbKF1lL+gsAMp4TW3PS1NUm ZAYYNQA/+OSGs9F/q7TYvLjyIg0JIf9RbszvwLkmtTS6os/yoJMUz0wnyy/wbC+nAHWi FDsePmyVbq4ggzpOQbn6BA1mDtKLRN0XJtZF1arvUA2XcyDszrk3Ya8fA95su0yxx3lg FrVzKXGlb76lMHPS4ak64MS/jK9NhfWSe1owj5GeCXpFJ3p+jnk5T+lKDpQTnpQKippz qTErNdpU14EyrVDoVVlmIwp5K4p0PmaSzRKZ0LhL81Op1VVxqJx/hwBuWtHoOF6YcSzR koDw== X-Gm-Message-State: AOAM533ZS9l/T5XjxAmNWd4vEJJhXgNcvC9DH3HZpGvg2WsMHmqL61hG 524YJyUGRQ1T+Y6p2V7ur8xUzT9CU0k92vKYT6I= X-Google-Smtp-Source: ABdhPJxHcUwoB7sNfjbv2DTu2fnQ5BYunR0SBJxk8gxMGuFYwty7cGEs9HePPRYNUnr2IjiXKO7lk8sGiWPL0uzwtjQ= X-Received: by 2002:a05:620a:142:: with SMTP id e2mr619262qkn.331.1589911536520; Tue, 19 May 2020 11:05:36 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::729; envelope-from=oguzismailuysal@gmail.com; helo=mail-qk1-x729.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <20200519141033.GU751@eeg.ccf.org> Xref: csiph.com gnu.bash.bug:16302 On Tue, May 19, 2020 at 8:36 PM Inian Vasanth wro= te: > > 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-Cond= itional-Expressions > to > explain that, any other primaries other than the ones mentioned above wil= l > be evaluated as a literal string result. I don't think that's necessary, under `[[=E2=80=A6]]`, it says Expressions may be combined using the following operators, listed in decreasing order of precedence: ( expression ) Returns the value of expression. This may be used to override the normal precedence of operators. With that it shouldn't be that hard to figure out `[[ (( x < y )) ]]` equals to `[[ x < y ]]` in function. > 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 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 groupin= g, > > 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 b= e > > 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 substitu= tion > > 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=3D$((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 expressio= n > > 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 no= t > > 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 --=20 O=C4=9Fuz