[Bug] comparisson operator `[[` not working as expected

[Bug] comparisson operator `[[` not working as expected

[Paulo Diovani]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Hello,

In version 5.9 the [[ ]] operator is behaving unexpectedly for the
following case:

$ watch ls &
$ [ $(jobs -l | wc -l) -gt 0 ] && echo jobs found || echo no jobs
jobs found
$ [[ $(jobs -l | wc -l) -gt 0 ]] && echo jobs found || echo no jobs
no jobs

Expected

The result should be the same, in this case, with both [ ] and [[ ]].
Actual

[[ $(jobs -l | wc -l) -gt 0 ]] exit status is > 0 when there are jobs
running.
Version information

   - Zsh zsh 5.9 (x86_64-pc-linux-gnu)

Previous version, 5.8.1 was working as expected.
Distros

Tested in the following distros

   - Arch Linux (bare metal, docker)
   - Debian Sid (docker)

-- 
Paulo Diovani Gonçalves,
blog.diovani.com / @paulodiovani <http://twitter.com/paulodiovani>

[-- Attachment #2: Type: text/html, Size: 7093 bytes --]

Re: [Bug] comparisson operator `[[` not working as expected

[Stephane Chazelas]

2022-06-20 15:32:32 -0300, Paulo Diovani:
[...]
> In version 5.9 the [[ ]] operator is behaving unexpectedly for the
> following case:
> 
> $ watch ls &
> $ [ $(jobs -l | wc -l) -gt 0 ] && echo jobs found || echo no jobs
> jobs found
> $ [[ $(jobs -l | wc -l) -gt 0 ]] && echo jobs found || echo no jobs
> no jobs
[...]

While I agree that looks like a bug (the output of jobs seems to
be empty when the command substitution is expanded inside
[[...]] or ((...)) or a[$(jobs)]=... at least in my tests), a
better approach here would be to use:

if (( $#jobstates > 0 )); then
  echo jobs found
else
  echo no jobs
fi

-- 
Stephane

Re: [Bug] comparisson operator `[[` not working as expected

[Paulo Diovani]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Thanks for the answer,

It could be an intentional change, but compared with the previous version
or bash the behavior is quite different, and it can cause issues with
several scripts.
Also, I didn’t find the change in behavior listed in the changelog for 5.9,
so it may be a new bug or regression.

I just use that line to define my PROMPT and I can easily update, but I
worry that the change could be more troublesome for other packages or
automation scripts.

On Mon, Jun 20, 2022 at 4:54 PM Stephane Chazelas <stephane@chazelas.org>
wrote:

> 2022-06-20 15:32:32 -0300, Paulo Diovani:
> [...]
> > In version 5.9 the [[ ]] operator is behaving unexpectedly for the
> > following case:
> >
> > $ watch ls &
> > $ [ $(jobs -l | wc -l) -gt 0 ] && echo jobs found || echo no jobs
> > jobs found
> > $ [[ $(jobs -l | wc -l) -gt 0 ]] && echo jobs found || echo no jobs
> > no jobs
> [...]
>
> While I agree that looks like a bug (the output of jobs seems to
> be empty when the command substitution is expanded inside
> [[...]] or ((...)) or a[$(jobs)]=... at least in my tests), a
> better approach here would be to use:
>
> if (( $#jobstates > 0 )); then
>   echo jobs found
> else
>   echo no jobs
> fi
>
> --
> Stephane
>


-- 
Paulo Diovani Gonçalves,
blog.diovani.com / @paulodiovani <http://twitter.com/paulodiovani>

[-- Attachment #2: Type: text/html, Size: 3378 bytes --]

Re: [Bug] comparisson operator `[[` not working as expected

[Bart Schaefer]

On Mon, Jun 20, 2022 at 11:33 AM Paulo Diovani <paulo@diovani.com> wrote:
>
> In version 5.9 the [[ ]] operator is behaving unexpectedly for the following case:

Yep, this is a bug, introduced when a different crashing bug was
fixed.  It's an off-by-one error skipping the first job in the table.

The relevant ChangeLog entry for the crash bug is

2022-03-30  Peter Stephenson  <p.stephenson@samsung.com>

        * 49906 (Bart), 49911: Doc/Zsh/builtins.yo,
        Doc/Zsh/mod_parameter.yo, Src/exec.c, Src/jobs.c,
        Test/W03jobparameters.ztst: Fix querying jobs in subshell.

diff --git a/Src/jobs.c b/Src/jobs.c
index e0e453ed8..25ceb81c4 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -2402,7 +2402,7 @@ bin_fg(char *name, char **argv, Options ops, int func)
            int curmaxjob, ignorejob;
            if (unset(MONITOR) && oldmaxjob) {
                jobptr = oldjobtab;
-               curmaxjob = oldmaxjob ? oldmaxjob - 1 : 0;
+               curmaxjob = oldmaxjob ? oldmaxjob : 0;
                ignorejob = 0;
            } else {
                jobptr = jobtab;

Re: [Bug] comparisson operator `[[` not working as expected

[Mikael Magnusson]

On 6/20/22, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mon, Jun 20, 2022 at 11:33 AM Paulo Diovani <paulo@diovani.com> wrote:
>>
>> In version 5.9 the [[ ]] operator is behaving unexpectedly for the
>> following case:
>
> Yep, this is a bug, introduced when a different crashing bug was
> fixed.  It's an off-by-one error skipping the first job in the table.
>
> The relevant ChangeLog entry for the crash bug is
>
> 2022-03-30  Peter Stephenson  <p.stephenson@samsung.com>
>
>         * 49906 (Bart), 49911: Doc/Zsh/builtins.yo,
>         Doc/Zsh/mod_parameter.yo, Src/exec.c, Src/jobs.c,
>         Test/W03jobparameters.ztst: Fix querying jobs in subshell.
>
> diff --git a/Src/jobs.c b/Src/jobs.c
> index e0e453ed8..25ceb81c4 100644
> --- a/Src/jobs.c
> +++ b/Src/jobs.c
> @@ -2402,7 +2402,7 @@ bin_fg(char *name, char **argv, Options ops, int
> func)
>             int curmaxjob, ignorejob;
>             if (unset(MONITOR) && oldmaxjob) {
>                 jobptr = oldjobtab;
> -               curmaxjob = oldmaxjob ? oldmaxjob - 1 : 0;
> +               curmaxjob = oldmaxjob ? oldmaxjob : 0;

Isn't this now just a very funny way to spell
  curmaxjob = oldmaxjob;
?

-- 
Mikael Magnusson

Re: [Bug] comparisson operator `[[` not working as expected

[Bart Schaefer]

On Mon, Jun 20, 2022 at 5:47 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> > -               curmaxjob = oldmaxjob ? oldmaxjob - 1 : 0;
> > +               curmaxjob = oldmaxjob ? oldmaxjob : 0;
>
> Isn't this now just a very funny way to spell
>   curmaxjob = oldmaxjob;
> ?

Now that you mention it, yes.  Removing the -1 was just the closest
equivalent to the patch that created the problem.