svn commit: r212374 - head/usr.bin/printf

[Jilles Tjoelker]

On Thu, Sep 09, 2010 at 07:27:40PM +0000, David E. O'Brien wrote:
> Author: obrien
> Date: Thu Sep  9 19:27:40 2010
> New Revision: 212374
> URL: http://svn.freebsd.org/changeset/base/212374

> Log:
>   Note bug in trying to printf(1) things like: '-%s\n' "foo"

> Modified:
>   head/usr.bin/printf/printf.1

> Modified: head/usr.bin/printf/printf.1
> ==============================================================================
> --- head/usr.bin/printf/printf.1	Thu Sep  9 18:51:50 2010	(r212373)
> +++ head/usr.bin/printf/printf.1	Thu Sep  9 19:27:40 2010	(r212374)
> @@ -355,3 +355,10 @@ Multibyte characters are not recognized 
>  a problem if
>  .Ql %
>  can appear inside a multibyte character).
> +.Pp
> +Trying to print a dash ("-") as the first character causes
> +.Nm
> +to interpet the dash as a program argument.
> +.Nm --
> +must be used before 
> +.Ar format .

I do not consider this a bug. POSIX requires printf to recognize -- and
pretty much all current implementations conform to this. Causing an
error for unrecognized options allows us to add options later on,
without fear of breaking scripts that use format strings starting with a
dash without -- protection.

Needing -- is not particularly onerous here as format strings are
usually constants.

A caveat could be added, but it is really echo(1) that is inconsistent
by not treating -- specially. The printf utility is consistent with most
other utilities in requiring --.

FWIW, the omission of hexadecimal character constants does not belong in
the BUGS section either. They are deliberately not provided, therefore
their omission is not a bug. (One reason is that there is no way to
force termination of such a sequence, unlike C where you can do things
like "\x1b" "c".)

-- 
Jilles Tjoelker