Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Rich Felker
On Mon, Nov 26, 2007 at 10:24:08PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Eric Blake on 11/26/2007 10:09 PM: > >> Again, go read POSIX and if you're still unclear file a RFI. But it's > >> very clear and bash is incorrect in this respect. > > >

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 11/26/2007 10:09 PM: >> Again, go read POSIX and if you're still unclear file a RFI. But it's >> very clear and bash is incorrect in this respect. > > I'm on the Austin group, and feel quite confident that I understand what

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Rich Felker
On Mon, Nov 26, 2007 at 10:09:11PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Rich Felker on 11/26/2007 10:02 PM: > > On Mon, Nov 26, 2007 at 09:54:52PM -0700, Eric Blake wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Pleas

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rich Felker on 11/26/2007 10:02 PM: > On Mon, Nov 26, 2007 at 09:54:52PM -0700, Eric Blake wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Please keep replies on the list, so that others may chime in.

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please keep replies on the list, so that others may chime in. According to Rich Felker on 11/26/2007 9:41 PM: >>> $ printf ---%s---\\n test >>> bash: printf: --: invalid option >> That's not a bug. If you insist on printing with a format string that

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rich Felker on 11/26/2007 8:43 PM: > $ printf ---%s---\\n test > bash: printf: --: invalid option That's not a bug. If you insist on printing with a format string that starts with -, POSIX requires that you use -- to end arguments, as in

Re: echo(1) non-conformant (processing -e and -E)

2007-11-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rich Felker on 11/26/2007 8:51 PM: > POSIX leaves behavior unspecified when -n is the first argument, and > also when any argument contains backslashes. However, if conformance > to the XSI part of SUSv3 is also desired, -e must be default

echo(1) non-conformant (processing -e and -E)

2007-11-26 Thread Rich Felker
When running in POSIX/sh mode, bash should either disable the echo builtin or stop giving special treatment to -e and -E. In particular, POSIX provides well-defined behavior for: echo -e bash gives: blank line posix gives: line containing only "-e" echo -E bash gives: blank line posix gives: line

nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Rich Felker
$ printf ---%s---\\n test bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] expected: ---test--- This seems to be the third bug I've found in bash's internal printf(1) which breaks conformance to POSIX. Could you either fix this, or else disable the printf (and po