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

Groups > gnu.bash.bug > #15199

Incorrect option processing in builtin printf(1)

Show all headers | View raw

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.

Back to gnu.bash.bug | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

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

csiph-web