Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Sam Liddicott <sam@liddicott.com>
Newsgroups: gnu.bash.bug
Subject: Re: %q with truncating size loses safeness of %q
Date: Mon, 20 Apr 2020 08:36:43 +0100
Lines: 29
Approved: bug-bash@gnu.org
Message-ID: <mailman.770.1587368247.3066.bug-bash@gnu.org>
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>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Robert Elz <kre@munnari.oz.au>, bug-bash@gnu.org
To: Chester Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <8c5bdd2c-bc61-a885-6a05-690ef7f515ce@case.edu>
Received-SPF: none client-ip=2a00:1450:4864:20::243; envelope-from=sam@liddicott.com; helo=mail-lj1-x243.google.com
Precedence: list
Xref: csiph.com gnu.bash.bug:16183

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