unreproducible bug with ${=...}

unreproducible bug with ${=...}

[frederik]

Dear Zsh Workers,

While working on some backup scripts I ran into what looks like an intermittent bug, which I was not able to reproduce sufficiently consistently to get a minimal test case. I'm not sure if that's helpful to report. Here is the relevant fragment:

     ...
     ssh=ssh
     rsync=(rsync)
     excludes=(/dvds /tmp .gvfs /fs)
     opts=(-a --partial
         ${=${:-"--exclude "$^excludes}}
         -e "$ssh")
     cmd=(sudo $rsync $opts $src_paths $dst_path)
     >&2 print -l $cmd;

Basically all arguments and variables are the same between one run and the next, but sometimes it prints

     ...
     --exclude /dvds
     --exclude /tmp
     --exclude .gvfs
     ...

(prompting a complaint from rsync), whereas usually I get the intended

     ...
     --exclude
     /dvds
     --exclude
     /tmp
     --exclude
     .gvfs
     ...

The other parts of the script don't do anything weird, there is a file locking part which creates traps on INT, TERM, and EXIT after some options setting:

     unsetopt localtraps # so the 'trap' lasts beyond the function
     setopt posix_traps # so that we can trap EXIT

Here is the value of IFS, I don't think I set it anywhere.

     $ echo -n \"$IFS\" | od -c
     0000000   "      \t  \n  \0   "
     0000006

If anyone has some advice about what may be causing this, or how I can debug it or try to get a minimal test case, I'm willing to spend a little more time. I imagine it's somehow my fault, but I can't think of what could be going on here.

I was running the command on an Intel Core 2 Duo laptop, with Arch (zsh 5.7.1).

Thanks,

Frederick

P.S. I switched to using "zip" expansion, as suggested by Mikachu on IRC, which seems more elegant and doesn't use IFS: ${${:---exclude}:^^excludes}

Re: unreproducible bug with ${=...}

[dana]

On 13 Dec 2019, at 22:53, frederik@ofb.net wrote:
> P.S. I switched to using "zip" expansion, as suggested by Mikachu on IRC,
> which seems more elegant and doesn't use IFS: ${${:---exclude}:^^excludes}

In this case you could also just do: --exclude=$^excludes

As to why your ${=...} result sometimes differs, the most obvious thing that
comes to mind is IFS getting changed somehow. But i don't know how that would
be happening intermittently. As far as debugging, i guess just add logging to
show what IFS is set to immediately before the command, and/or run the script
with -x if you can?

dana

Re: unreproducible bug with ${=...}

[frederik]

Thank you dana for the reply.

On Sat, Dec 14, 2019 at 09:59:49AM -0600, dana wrote:
>On 13 Dec 2019, at 22:53, frederik@ofb.net wrote:
>> P.S. I switched to using "zip" expansion, as suggested by Mikachu on IRC,
>> which seems more elegant and doesn't use IFS: ${${:---exclude}:^^excludes}
>
>In this case you could also just do: --exclude=$^excludes

Thanks, that's a good point, what with rsync following the GNU long option conventions.

>As to why your ${=...} result sometimes differs, the most obvious thing that
>comes to mind is IFS getting changed somehow. But i don't know how that would
>be happening intermittently. As far as debugging, i guess just add logging to
>show what IFS is set to immediately before the command, and/or run the script
>with -x if you can?

Yeah, by the time I made that edit to print IFS, I was having a hard time reproducing.

I do have a shell function which I use a lot that sets IFS within a () subshell. That's the only occurrence of the variable in my .zshrc.

Thanks,

Frederick