printf and POSIX compliance

printf and POSIX compliance

[Stephane CHAZELAS]

Hello all, and thank you for the very good job

I read at
http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
that, according to POSIX:

3- In addition to the escape sequences shown in the Base
   Definitions volume of IEEE Std 1003.1-2001, Chapter 5, File
   Format Notation ( '\\' , '\a' , '\b' , '\f' , '\n' , '\r' ,
   '\t' , '\v' ), "\ddd" , where ddd is a one, two, or
   three-digit octal number, shall be written as a byte with the
   numeric value specified by the octal number.

So

printf '\377\0377' | od -c

should return:
0000000 377 037   7
0000003

zsh printf gives:
0000000   \   3   7   7 377
0000005

zsh man pages says that sames sequences as for echo are
recognized. That's not what POSIX requires.

Note that neither bash nor GNU printf behave better.

The "printf '%b' '\0ooo'" is OK though.

--
Stéphane

Re: printf and POSIX compliance

[DervishD]

    Hi Stephane :)

> http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
> that, according to POSIX:

    That is Single Unix Specification, not POSIX, am I wrong?

> 3- In addition to the escape sequences shown in the Base

    Oh, additional sequences, not POSIX ones. Ok, then :)

> Note that neither bash nor GNU printf behave better.

    The GNU printf says in its info manual that '\0ooo' is
interpreted as an octal number, but doesn's say anything about \ooo
where the 'o' are octal digits. It barfs in your example saying that
'\3' is not a valid escape sequence :(( I notified and got fixed a
bug about GNU printf argument handling a time ago, for not being SuS
compliant. Don't know the current status of SuS compliance that GNU
shell utilities have :??? Wait for GNU coreutils.

    BTW, as far as I know, zsh has not a printf builtin.

    Raúl

Re: printf and POSIX compliance

[Stephane CHAZELAS]

On Tue, Feb 04, 2003 at 07:26:11PM +0100, DervishD wrote:
> > http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
> > that, according to POSIX:
> 
>     That is Single Unix Specification, not POSIX, am I wrong?

I must confess I've not understood all of this imbroglio of
obscure specifications, but had the rough idea this SUS was a
step forward after POSIX. Well, it's also an IEEE (or maybe Open
Group registered at IEEE???) document and it's publicly
available.

> > 3- In addition to the escape sequences shown in the Base
> 
>     Oh, additional sequences, not POSIX ones. Ok, then :)

No, you misunderstood that point. Read at:
http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
These are additional sequences over those defined at:
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap05.html

> > Note that neither bash nor GNU printf behave better.
> 
[...]
>     BTW, as far as I know, zsh has not a printf builtin.

I was actually speaking of printf builtin in zsh developpement
series (4.1.1-dev-x), aka "print -f"

zsh ChangeLog:

  2001-10-05  Oliver Kiddle  <opk@zsh.org>

        * 15851, 15948: Src/builtin.c, Doc/Zsh/builtins.yo: add printf
        builtin with basic POSIX functionality


Actually, the only portable (as far as I know) way to display my
first name with any printf (and ascii chars only) is:

printf '%b' 'St\0351phane'

printf 'St\351phane'
will break GNU and zsh ones (not bash)

printf 'St\0351phane'
will break POSIX (or whatever standard is used in recent unices)
ones (such as HPUX's one) (not bash, GNU nor zsh). I don't know
about ksh93's one.

So, that doesn't really matter if zsh printf adopts one syntax
or another, but it may be wise to pick the one that is more
likely to eventually become standard one day. Maybe the bash
behavior (\351 and \0351 both expanding to é) is the least
worst...

-- 
Stéphane

Re: printf and POSIX compliance

[Peter Stephenson]

Stephane CHAZELAS wrote:
> On Tue, Feb 04, 2003 at 07:26:11PM +0100, DervishD wrote:
> > > http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
> > > that, according to POSIX:
> > 
> >     That is Single Unix Specification, not POSIX, am I wrong?
> 
> I must confess I've not understood all of this imbroglio of
> obscure specifications, but had the rough idea this SUS was a
> step forward after POSIX. Well, it's also an IEEE (or maybe Open
> Group registered at IEEE???) document and it's publicly
> available.

The Austin Group which is revising the standard is steering it through
IEEE, SUS and ISO procedures.  If I've followed the developments
correctly, the 2002 version available at the Open Group site is now
approved by all relevant bodies, with identical wording.

Unfortunately we're a bit erratic at following it; nobody's really got
the time to keep track of it in detail.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: printf and POSIX compliance

[DervishD]

    Hi Stephane :)

> >     That is Single Unix Specification, not POSIX, am I wrong?
> I must confess I've not understood all of this imbroglio of
> obscure specifications

    Neither have I O:)) And the number of specs seems to grow on a
daily basis...

> > > Note that neither bash nor GNU printf behave better.
> [...]
> >     BTW, as far as I know, zsh has not a printf builtin.
> I was actually speaking of printf builtin in zsh developpement
> series (4.1.1-dev-x), aka "print -f"

    Oh, sorry, didn't know that the development branch of zsh
implements a printf builtin O:)

> So, that doesn't really matter if zsh printf adopts one syntax or
> another, but it may be wise to pick the one that is more likely to
> eventually become standard one day. Maybe the bash behavior (\351
> and \0351 both expanding to é) is the least worst...

    I think that is better to stuck to an standard, being that POSIX
or SuS. Since SuS gives its spec freely (I mean, you don't have to
pay for giving free software to the community that is SuS compliant)
I prefer that standard over the rest, but obviously is a personal
choice ;)))

    Being bash-compliant is, IMHO, just a way of standardize bad
behaviour. If GNU printf is broken, non POSIX or SuS compliant, then
submit a bug report. The shellutils developers care about standard
compliance, I've submitted such bug reports in the past.

    Bye :)
    Raúl

Re: printf and POSIX compliance

[Oliver Kiddle]

On 4 Feb, you wrote:
> Hello all, and thank you for the very good job
> 
> I read at
> http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
> that, according to POSIX:
> 
> 3- In addition to the escape sequences shown in the Base
>    Definitions volume of IEEE Std 1003.1-2001, Chapter 5, File
>    Format Notation ( '\\' , '\a' , '\b' , '\f' , '\n' , '\r' ,
>    '\t' , '\v' ), "\ddd" , where ddd is a one, two, or
>    three-digit octal number, shall be written as a byte with the
>    numeric value specified by the octal number.
> 
> So
> 
> printf '\377\0377' | od -c
> 
> should return:
> 0000000 377 037   7
> 0000003

Okay, that's what printf(3) and ksh93's printf do.

> zsh man pages says that sames sequences as for echo are
> recognized. That's not what POSIX requires.

It uses the same code as for echo and $'...' and doing otherwise would
seem a bit unpleasant to me. That said, it seems to be what ksh93 does.
In ksh, $'...' and printf work that way while print does something
different.

Note also that the behaviour of \c should probably be to cancel further
output in printf but it isn't (again because I used the same function
as is used by echo).

It's an easy enough thing to change though. Should I? And what should
it do for print and for posix quotes?

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

PATCH: unset -v (was Re: printf and POSIX compliance)

[Oliver Kiddle]

On 5 Feb, Peter wrote:
> 
> The Austin Group which is revising the standard is steering it through
> IEEE, SUS and ISO procedures.  If I've followed the developments
> correctly, the 2002 version available at the Open Group site is now
> approved by all relevant bodies, with identical wording.
> 
> Unfortunately we're a bit erratic at following it; nobody's really got
> the time to keep track of it in detail.

It seems from it that one of the things it defines is that unset should
take a -v flag to specify that variables are being unset. If neither -f
nor -v is specified, it unsets variables. bash breaks this last
condition (probably because older versions of the standard didn't define
that) so unset -v is used a bit in bash scripts.
Anyway, all we need to do is ignore any -v option to unset. Unless anyone
says otherwise I'll commit this to 4.0 too because it is sufficiently tiny.

Oliver

diff -ur zsh-4.1-20030211/Doc/Zsh/builtins.yo zsh.new/Doc/Zsh/builtins.yo
--- zsh-4.1-20030211/Doc/Zsh/builtins.yo	Fri Feb  7 18:05:39 2003
+++ zsh.new/Doc/Zsh/builtins.yo	Tue Feb 11 12:04:41 2003
@@ -1391,7 +1391,7 @@
 )
 findex(unset)
 cindex(parameters, unsetting)
-item(tt(unset) [ tt(-fm) ] var(name) ...)(
+item(tt(unset) [ tt(-fmv) ] var(name) ...)(
 Each named parameter is unset.
 Local parameters remain local even if unset; they appear unset within scope,
 but the previous value will still reappear when the scope ends.
@@ -1404,6 +1404,9 @@
 be quoted) and all parameters with matching names are unset.  Note that this
 cannot be used when unsetting associative array elements, as the subscript
 will be treated as part of the pattern.
+
+The tt(-v) flag specifies that var(name) refers to parameters. This is the
+default behaviour.
 
 tt(unset -f) is equivalent to tt(unfunction).
 )
diff -ur zsh-4.1-20030211/Src/builtin.c zsh.new/Src/builtin.c
--- zsh-4.1-20030211/Src/builtin.c	Fri Feb  7 18:05:41 2003
+++ zsh.new/Src/builtin.c	Tue Feb 11 11:53:43 2003
@@ -126,7 +126,7 @@
     BUILTIN("unalias", 0, bin_unhash, 1, -1, 0, "m", "a"),
     BUILTIN("unfunction", 0, bin_unhash, 1, -1, 0, "m", "f"),
     BUILTIN("unhash", 0, bin_unhash, 1, -1, 0, "adfm", NULL),
-    BUILTIN("unset", BINF_PSPECIAL, bin_unset, 1, -1, 0, "fm", NULL),
+    BUILTIN("unset", BINF_PSPECIAL, bin_unset, 1, -1, 0, "fmv", NULL),
     BUILTIN("unsetopt", 0, bin_setopt, 0, -1, BIN_UNSETOPT, NULL, NULL),
     BUILTIN("wait", 0, bin_fg, 0, -1, BIN_WAIT, NULL, NULL),
     BUILTIN("whence", 0, bin_whence, 0, -1, 0, "acmpvfsw", NULL),

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.