Re: [Help-bash] Escape Character and NewLine

[Fernando Basso]

According to the POSIX spec on `printf',

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html

the "format" shall be used as the format string as described in the File
Format Notation docs:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html

And that doc, in turn, states that:

""
Each conversion specifier character shall result in fetching
zero or more arguments. The results are undefined if there
are insufficient arguments for the format. If the format is
exhausted while arguments remain, the excess arguments shall
be ignored.
""

Is that the direct opposite of Bash's `printf'? `help printf':

""
The format is re-used as necessary to consume all of the
arguments. If there are fewer arguments than the format
requires, extra format specifications behave as if a zero
value or null string, as appropriate, had been supplied.
""

By "opposite" I mean that the POSIX spec on `printf' says that extra
arguments are ignored, and Bash's `printf' , on the other hand, re-uses
the format specifier if there are more arguments than the format.

If so, I would assume that POSIX `printf' would behave like this:

$ printf '"%s %s"\n' foo bar baz
"foo bar"
$ printf '"%d %d"\n' 10 20 30
"10 20"

While Bash's `printf' would produce:

$ printf '"%s %s"\n' foo bar baz
"foo bar"
"baz "
$ printf '"%d %d"\n' 10 20 30
"10 20"
"30 0"

Is this interpretation near the mark?


On Tue, Sep 17, 2019 at 9:55 AM Greg Wooledge <address@hidden> wrote:
>
> On Tue, Sep 17, 2019 at 07:15:23AM +1000, David wrote:
> > Wherever a printf command is provided, this is the usual behaviour.
> >
> > The bash builtin printf is documented here:
> > $ help printf | grep 're-used'
> >     The format is re-used as necessary to consume all of the arguments.  If
> >
> > For more extensive documentation, try the command
> >   man 3 printf
> > or read a book on the C language.
>
> To be complete, the original printf() is a function in the C library,
> documented in printf(3).  That's the base line.
>
> Then, there's the POSIX printf(1) command, documented at
> <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html>
> and sometimes also available as a local man page, e.g. printf(1p) or
> similar.
>
> If printf(1) is installed as a local man page, that may indicate some
> features or extensions of your local /bin/printf or /usr/bin/printf
> command, just in case that differs from POSIX.  However, you will almost
> never actually use this command, because...
>
> ... printf is also a bash builtin, documented in bash(1) and in "help
> printf" inside bash.
>
> "help printf" extends and refers to printf(1) which really means
> printf(1p) or the URL given above.  That document, in turn, extends
> and refers to printf(3).
>
> Another way to look at it is that bash's printf builtin is
> a third-generation tool.  The builtin printf adds features like
> "-v varname" so that you can avoid forking every time you want to
> emulate sprintf(), and %q so that you can use eval more safely later.
> This is on top of the POSIX printf command, which adds features like
> implicit looping, %b, and that thing about the leading character being
> a single-quote or double-quote.  Which in turn is on top of printf(3),
> which offers the basic functionality.
>