Re: %q with truncating size loses safeness of %q

From	Sam Liddicott <sam@liddicott.com>
Newsgroups	gnu.bash.bug
Subject	Re: %q with truncating size loses safeness of %q
Date	2020-04-20 08:36 +0100
Message-ID	<mailman.770.1587368247.3066.bug-bash@gnu.org> (permalink)
References	<4bacf2f0-9802-67d3-f30b-80e37d058a4a@case.edu> <CAOj-5WCqxqh=Gcda9k6y4orQaQYXPgsOgNEOVN1AdZQrkCVbtg@mail.gmail.com> <22039.1587163072@jinx.noi.kre.to> <8c5bdd2c-bc61-a885-6a05-690ef7f515ce@case.edu> <CAOj-5WDMyj4GG5TV6tfW9wOS=YjZ4ENVqOpv5zfk01kZbs05dQ@mail.gmail.com>

Show all headers | View raw

On Sun, 19 Apr 2020 at 20:40, Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 4/17/20 6:37 PM, Robert Elz wrote:
>
> > This happens only because of the cheap way we (and I presume you)
> > implement things - in any rational scheme, it would take the precision
> > chars from the source string, and then quote them.

That, or at least refuse to emit a dangling escape char. There are
arguments against both.
GNU Coreutils printf rejects size specifiers for %q and %b, probably
for this reason.

> Nobody, including POSIX, is rational, then.

Chet, I don't know that POSIX attempt to make a guarantee about output
being reusable as shell input at all, so I don't know that we need to
fallback on POSIX as a reason to break that guarantee.

I that although GNU coreutils printf doesn't exhibit this behaviour of
%q (entirely rejecting size specifiers for it) ksh does exhibit this
behaviour, I will make a report there.

This is another candidate for shellcheck I guess, which reminds me
that I forgot to submit the one for leaky named file descriptors (in
contrast to numeric ones).

Sam

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: %q with truncating size loses safeness of %q Sam Liddicott <sam@liddicott.com> - 2020-04-20 08:36 +0100

csiph-web