On Sat, Jul 06, 2024 at 07:46:51PM +0200, ??? wrote:
> On Sat, Jul 06, 2024 at 06:09:16PM +0200, tlaro...@kergis.com wrote:
> > With sh(1), and specially on NetBSD, I tend to expect this behavior:
> >
> > $ line=$(printf "a\tb")
> > $ echo $line | od -a
> > 0000000 a sp b nl
> > 0000004
>
> line has the value a, tab, b.
>
> Given the default value of IFS (space, tab, newline):
> $line splits this into a, b,
> so echo is as-if it were executed with "echo", "a", "b".
>
> POSIX recommends against using echo in favour of printf due to the
> nonportability of echo, but in this case this is okay
> (no \es, first argument doesn't start with -).
>
OK, this was my expectation.
> Thus (POSIX.1-2024 line numbers):
> 93207 STDOUT
> 93208 The echo utility arguments shall be separated by single <space>
> 93209 characters and a <newline> character shall follow the last argument.
>
> So echo produces a, space, b, newline.
>
Uh! I missed the STDOUT paragraph and only read the DESCRIPTION:
"The echo utility writes its arguments to standard output, followed by
a <newline>. If there are no arguments, only the <newline> is
written."
I will argue that the "single <space>" precision could be put in the
description since it is as essential as the trailing newline, and
since outputing to stdout is not a by product but the core of what it
does...
> Your sample above is (for the default IFS), guaranteed to hold.
>
> If IFS=' ' (so tab doesn't split line) or echo "$line" then you'd expect
> $ echo "$line" | od -ta
> 0000000 a ht b nl
> 0000004
>
Thanks. I think then that dash(1) is, in some circumstances (what
version? what libc? Bug report was from a Debian node and I couldn't
reproduce this with the dash in pkgsrc) at fault and doesn't split the
arguments and passes "a\tb" as a single arg to echo.
Thanks,
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
