Re: [BUG] zf_ln complains about the wrong argument

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

> On 22 August 2021 at 22:05 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Peter Stephenson wrote on Sun, 22 Aug 2021 20:24 +00:00:
> > Also seems a good idea to turn a null string into a couple of quotes.  I
> > thought of modifying the error message handler but this has too many
> > knock on effects.
> 
> What "knock on effects"?  Extending zwarning() with a %q format code
> that takes a «char *» and outputs it quoted seems like a good idea and
> shouldn't break anything.  Will handle filenames with spaces, too.

This is certainly all stuff that's accumulated rather than been planned
over the years, but having a harder look I think it's mostly not too bad
the way it is.  I think the basics are currently as follows.

%s as implemented in errors and warnings is already not a straight 
printf %s: it uses nicezputs() to emphasise visibility rather than quoting,
i.e. it's there to make it easy to see what the error is about, rather than
easy to copy back into the shell.  Given the error is about something that
would usually be either in a script or on the command line, this doesn't
seem a bad way of doing it, on reflection.

As far as quoting is concerned, the state of the art is to use `%s' (i.e.
with those literal quotes) if it seems necessary to draw attention to the
argument, i.e. it could get lost otherwise.  There are a  lot of cases
where we don't do this, however, but they can easily be changed.  The
combination of this and nicezputs() means you can always see what's
there, unless there are very subtle cases I've missed.

So I think the consistent way of handling a case like this is to turn
%s into `%s'.  That both makes it visible what's going on and makes
the output consistent with similar cases elsewhere.

Does that seem reasonable?  I can't think of a strong argument for a
more widespread change given it's sort of working and even sort of
potentially consistent.

pws