On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote:
> 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
> [...]
> > The current POSIX says that %b was added so that on a non-XSI
> > system, you could do:
> >
> > my_echo() {
> > printf %b\\n "$*"
> > }
>
> That is dependant on the current value of $IFS. You'd need:
>
> xsi_echo() (
> IFS=' '
> printf '%b\n' "$*"
> )
Let's read the standard in context (Issue 8 draft 3 page 2793 line 92595):
"
The printf utility can be used portably to emulate any of the traditional
behaviors of the echo
utility as follows (assuming that IFS has its standard value or is unset):
• The historic System V echo and the requirements on XSI implementations in
this volume of
POSIX.1-202x are equivalent to:
printf "%b\n" "$*"
"
So yes, the standard does mention the requirement to have a sane IFS,
and I failed to include that in my one-off implementation of
my_echo(). Thank you for pointing out a more robust version.
>
> Or the other alternatives listed at
> https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/65819#65819
>
> [...]
> > Bash already has shopt -s xpg_echo
>
> Note that in bash, you need both
>
> shopt -s xpg_echo
> set -o posix
>
> To get a XSI echo. Without the latter, options are still
> recognised. You can get a XSI echo without those options with:
>
> xsi_echo() {
> local IFS=' ' -
> set +o posix
> echo -e "$*\n\c"
> }
>
> The addition of those \n\c (noop) avoids arguments being treated as
> options if they start with -.
As an extension, Bash (and Coreutils) happen to honor \c always, and
not just for %b. But POSIX only requires \c handling for %b.
And while Issue 8 has taken steps to allow implementations to support
'echo -e', it is still not standardized behavior; so your xsi_echo()
is bash-specific (which is not necessarily a problem, as long as you
are aware it is not portable).
> [...]
> > The Austin Group also felt that standardizing bash's behavior of %q/%Q
> > for outputting quoted text, while too late for Issue 8, has a good
> > chance of success, even though C says %q is reserved for
> > standardization by C. Our reasoning there is that lots of libc over
> > the years have used %qi as a synonym for %lli, and C would be foolish
> > to burn %q for anything that does not match those semantics at the C
> > language level; which means it will likely never be claimed by C and
> > thus free for use by shell in the way that bash has already done.
> [...]
>
> Note that %q is from ksh93, not bash and is not portable across
> implementations and with most including bash's gives an output
> that is not safe for reinput in arbitrary locales (as it uses
> $'...' in some cases), not sure it's a good idea to add it to
> the standard, or at least it should come with fat warnings about
> the risk in using it.
%q is NOT being added to Issue 8, but $'...' is. Bug 1771 asked if %q
could be added to Issue 8, but it came it past the deadline for
feature requests, so the best we could do is add a FUTURE DIRECTIONS
blurb that mentions the idea. But since FUTURE DIRECTIONS is
non-normative, we can always change our mind in Issue 9 and delete
that text if it turns out we can't get consensus to standardize some
form of %q/%Q after all.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
