On Sat, Jul 06, 2024 at 02:47:20PM -0700, Greg A. Woods wrote:
> At Sat, 6 Jul 2024 20:09:24 +0200, tlaro...@kergis.com wrote:
> Subject: Re: POSIX.2, IFS and echo command
> >
> > Thanks. I think then that dash(1) is, in some circumstances (what
> > version? what libc? Bug
At Sat, 6 Jul 2024 20:09:24 +0200, tlaro...@kergis.com wrote:
Subject: Re: POSIX.2, IFS and echo command
>
> 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
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
> > 000a sp b nl
> > 004
>
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
> 000a sp b nl
> 004
line has the value a, tab, b.
Given the default value of IFS (space,
It's not a bug report, it's a search for enlightment.
KerTeX is used on many systems, and my own compilation/installation
framework uses a very limited subset of POSIX.2 utilities, starting of
course by sh(1).
With sh(1), and specially on NetBSD, I tend to expect this behavior:
$ line=$(printf "
