* printf and POSIX compliance @ 2003-02-04 15:44 Stephane CHAZELAS 2003-02-04 18:26 ` DervishD 2003-02-11 8:29 ` Oliver Kiddle 0 siblings, 2 replies; 7+ messages in thread From: Stephane CHAZELAS @ 2003-02-04 15:44 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: printf and POSIX compliance 2003-02-04 15:44 printf and POSIX compliance Stephane CHAZELAS @ 2003-02-04 18:26 ` DervishD 2003-02-05 13:10 ` Stephane CHAZELAS 2003-02-11 8:29 ` Oliver Kiddle 1 sibling, 1 reply; 7+ messages in thread From: DervishD @ 2003-02-04 18:26 UTC (permalink / raw) To: Stephane CHAZELAS; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: printf and POSIX compliance 2003-02-04 18:26 ` DervishD @ 2003-02-05 13:10 ` Stephane CHAZELAS 2003-02-05 13:42 ` Peter Stephenson 2003-02-05 14:41 ` printf and POSIX compliance DervishD 0 siblings, 2 replies; 7+ messages in thread From: Stephane CHAZELAS @ 2003-02-05 13:10 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: printf and POSIX compliance 2003-02-05 13:10 ` Stephane CHAZELAS @ 2003-02-05 13:42 ` Peter Stephenson 2003-02-11 12:09 ` PATCH: unset -v (was Re: printf and POSIX compliance) Oliver Kiddle 2003-02-05 14:41 ` printf and POSIX compliance DervishD 1 sibling, 1 reply; 7+ messages in thread From: Peter Stephenson @ 2003-02-05 13:42 UTC (permalink / raw) To: zsh-workers 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. ********************************************************************** ^ permalink raw reply [flat|nested] 7+ messages in thread
* PATCH: unset -v (was Re: printf and POSIX compliance) 2003-02-05 13:42 ` Peter Stephenson @ 2003-02-11 12:09 ` Oliver Kiddle 0 siblings, 0 replies; 7+ messages in thread From: Oliver Kiddle @ 2003-02-11 12:09 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: printf and POSIX compliance 2003-02-05 13:10 ` Stephane CHAZELAS 2003-02-05 13:42 ` Peter Stephenson @ 2003-02-05 14:41 ` DervishD 1 sibling, 0 replies; 7+ messages in thread From: DervishD @ 2003-02-05 14:41 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: printf and POSIX compliance 2003-02-04 15:44 printf and POSIX compliance Stephane CHAZELAS 2003-02-04 18:26 ` DervishD @ 2003-02-11 8:29 ` Oliver Kiddle 1 sibling, 0 replies; 7+ messages in thread From: Oliver Kiddle @ 2003-02-11 8:29 UTC (permalink / raw) To: Stephane CHAZELAS; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-02-11 12:06 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-04 15:44 printf and POSIX compliance Stephane CHAZELAS 2003-02-04 18:26 ` DervishD 2003-02-05 13:10 ` Stephane CHAZELAS 2003-02-05 13:42 ` Peter Stephenson 2003-02-11 12:09 ` PATCH: unset -v (was Re: printf and POSIX compliance) Oliver Kiddle 2003-02-05 14:41 ` printf and POSIX compliance DervishD 2003-02-11 8:29 ` Oliver Kiddle
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).