Re: qpdf or bashcompinit completion bug

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2025-08-18 21:06:19 +0100, Stephane Chazelas wrote:
> On 2025-08-18 21:00, Vincent Lefevre wrote:
> > On 2025-08-18 20:47:49 +0100, Stephane Chazelas wrote:
> > > On 2025-08-18 20:27, Vincent Lefevre wrote:
> > > [...]
> > > > /usr/share/zsh/vendor-completions/_qpdf just contains:
> > > >
> > > > #compdef qpdf
> > > > eval $(/usr/bin/qpdf --completion-zsh)
> > > [...]
> > > 
> > > In any case, that's wrong as that unquoted $(...) requests
> > > IFS-splitting on
> > > the output of qpdf.
> > > 
> > > Should be:
> > > 
> > > eval "$(/usr/bin/qpdf --completion-zsh)"
> > 
> > Isn't this equivalent here?
> [...]
> 
> That depends on what IFS contains at the time that code is evaluated. With
> the default value of $' \t\n\0', it would be equivalent with the output that
> qpdf currently gives me, with other values or if qpdf starts to output
> several lines of code in future versions, it will likely fail in interesting
> ways and may run random commands.

I would not expect IFS to have changed to a non-standard value for
the completion functions. Or should these functions be written in
such a way they should work for any IFS value?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)