Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15199 > unrolled thread

Incorrect option processing in builtin printf(1)

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Incorrect option processing in builtin printf(1) kre@munnari.OZ.AU - 2019-07-23 00:56 +0700
    Re: Incorrect option processing in builtin printf(1) Stephane Chazelas <stephane.chazelas@gmail.com> - 2019-07-22 20:48 +0100
    Re: Incorrect option processing in builtin printf(1) Eric Blake <eblake@redhat.com> - 2019-07-22 14:55 -0500
    Re: Incorrect option processing in builtin printf(1) Stephane Chazelas <stephane.chazelas@gmail.com> - 2019-07-22 21:10 +0100

#15199 — Incorrect option processing in builtin printf(1)

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: netbsd
Compiler: gcc
Compilation CFLAGS: -O2 -D_FORTIFY_SOURCE=2 -I/usr/include -Wno-parentheses -Wno-format-security
uname output: NetBSD jinx.noi.kre.to 8.99.30 NetBSD 8.99.30 (1.1-20190114) #9: Mon Jan 14 13:29:08 ICT 2019  kre@onyx.coe.psu.ac.th:/usr/obj/testing/kernels/amd64/JINX amd64
Machine Type: x86_64--netbsd

Bash Version: 5.0
Patch Level: 7
Release Status: release

Description:
	POSIX specifies that printf(1) has no options, and by not
	specifying that it is intended to comply with XBD 12.2 effectivly
	says that it is not.   That is, in printf, the first arg is
	always the format string, whatever it contains.

	So
		printf ---		should print three - chars to stdout
		printf -%d 3		should print -3 to stdout
	those do not work in bash (nor do any similar cases), even when bash
	is in posix mode.

Repeat-By:
	As above - start the format string with a '-'.

	Note that this can fixed withpit sacrificing bash's "-v var"
	option, as POSIX also says that if the format arg contains no
	% conversions, and there are more following args, then the
	results are unspecified.   "-v" contains no % conversions,
	and yet there are more args (the var name for one) so this
	is a case where the results are unspecofoed, and bash can
	do what ot likes.

	However
		printf -v
	must write "-v" to stdout, not give a usage message about a
	mssing arg to the 'v' option (which this is not).

Fix:
	Not a fix but a suggestion:  if the arg count is <= 1
	(that's argc-1 as it is when printf starts) or if argv[1]
	contains a '%', then skip getopt() processing, and simply
	use argv[1] as the format.   If the arg count is > 1, and
	argv[1] contains no '%' chars, then go ahead and do getopt()
	and anything the results of that cause to happen.

	The NetBSD printf has (quite) recently been changed to work
	like that - previously it had been made to simply drop getopt()
	processing all the time, but apparently some stupid scripts
	believe that it is correct to write:
		printf -- format args
	(it isn't, nor should it ever be needed) and broke because of
	that change.  That now "works" again because of the above hack.

	Please, let's try to avoid losing control of printf like what
	happened to echo, stick to the requirements of POSIX where they
	apply and actually speficy the output required.

[toc] | [next] | [standalone]

#15200

2019-07-23 00:56:59 +0700, kre@munnari.OZ.AU:
[...]
> 	POSIX specifies that printf(1) has no options, and by not
> 	specifying that it is intended to comply with XBD 12.2 effectivly
> 	says that it is not.   That is, in printf, the first arg is
> 	always the format string, whatever it contains.
[...]

If that was the case, then that would be bug in the POSIX
specification. I can't find a single printf implementations
where printf -- outputs -- (I tried bash, zsh, ksh93, GNU, yash,
busybox, busybox ash, Solaris /bin/printf).

Even if POSIX didn't mandate

printf -- -%s x

to output -x, I'd say it would be a bug in the POSIX
specification (it looks like it is).

-- 
Stephane

[toc] | [prev] | [next] | [standalone]

#15202

[Multipart message — attachments visible in raw view] — view raw

On 7/22/19 2:48 PM, Stephane Chazelas wrote:
> 2019-07-23 00:56:59 +0700, kre@munnari.OZ.AU:
> [...]
>> 	POSIX specifies that printf(1) has no options, and by not
>> 	specifying that it is intended to comply with XBD 12.2 effectivly
>> 	says that it is not.   That is, in printf, the first arg is
>> 	always the format string, whatever it contains.
> [...]
> 
> If that was the case, then that would be bug in the POSIX
> specification. I can't find a single printf implementations
> where printf -- outputs -- (I tried bash, zsh, ksh93, GNU, yash,
> busybox, busybox ash, Solaris /bin/printf).
> 
> Even if POSIX didn't mandate
> 
> printf -- -%s x
> 
> to output -x, I'd say it would be a bug in the POSIX
> specification (it looks like it is).

POSIX _does_ mandate 'printf -- -%s x' to output exactly '-x', by virtue
of the fact that it mandates all utilities (other than special builtins)
with the specification 'OPTIONS None.' to parse and ignore '--' as the
end of options, whether or not the utility takes options as an
extension.  If NetBSD broke that behavior, that is a bug in NetBSD's
shell, not bash nor POSIX.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[toc] | [prev] | [next] | [standalone]

#15203

2019-07-22 14:55:05 -0500, Eric Blake:
[...]
> > Even if POSIX didn't mandate
> > 
> > printf -- -%s x
> > 
> > to output -x, I'd say it would be a bug in the POSIX
> > specification (it looks like it is).
> 
> POSIX _does_ mandate 'printf -- -%s x' to output exactly '-x', by virtue
> of the fact that it mandates all utilities (other than special builtins)
> with the specification 'OPTIONS None.' to parse and ignore '--' as the
> end of options, whether or not the utility takes options as an
> extension.  If NetBSD broke that behavior, that is a bug in NetBSD's
> shell, not bash nor POSIX.
[...]

Yes, thanks for pointing to the right section. I wish POSIX made
it clearer. Having it spread like that in different sections
with no full linking within them is suboptimal. The special
treatment of special builtins seems bogus to me as well (like
the fact that it seems it makes : "$x" unspecified unless $x can
be guaranteed not to start with -; the description of the colon
utility with its "expands its arguments" is bogus anyway).

-- 
Stephane

[toc] | [prev] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web