Re: CVS commit: src/usr.bin/printf
Date:Sun, 28 Jun 2020 22:58:52 +0300 From:Valery Ushakov Message-ID: <20200628195852.gc20...@pony.stderr.spb.ru> | but I'd expect people that actually use IFS with octal digits | or a backslash to also understand and know how to add necessary | quoting in that case. You'd think so, right, but ... and that assumes that the person writing the printf code (copying the example from the man page) knows what IFS is, or that it might have been altered. | Though perhaps it makes sense to them back for | pedagogical purposes. That, and because it simply is the right way to code in sh 99% of the time - omitting needed quotes is a major source of bizarre bugs. When they're like this, and only trigger in unusual circumstances, they're ever harder to find. kre
Re: CVS commit: src/usr.bin/printf
On Sun, Jun 28, 2020 at 21:52:23 +0700, Robert Elz wrote: > Date:Fri, 26 Jun 2020 22:05:05 + > From:"Valeriy E. Ushakov" > Message-ID: <20200626220505.e9030f...@cvs.netbsd.org> > > | Modified Files: > | src/usr.bin/printf: printf.1 > | > | Log Message: > | Drop redundant quoting in the nested printf example. > > I don't think that is correct, the quotes around 0x0A were obviously > redundant (and changing it to 0x0a doesn't alter that), but those > around the $(printf ...) are not - without those the result from the > command substitution would be subject to field splitting, and if IFS > happens to contain a \ or an octal digit, bad things will happen. > > In general it is never a good idea to omit quotes around sh word > expansions except in the cases where you actually want field splitting > (or pathname expansion, etc) to happen (and sometimes except in the > contexts where those don't occur anyway, like x=$whatever) > > For the example in question, try running it with IFS=1 or IFS=2 > to see what I mean. Right, but I'd expect people that actually use IFS with octal digits or a backslash to also understand and know how to add necessary quoting in that case. Though perhaps it makes sense to them back for pedagogical purposes. -uwe
Re: CVS commit: src/usr.bin/printf
Date:Fri, 26 Jun 2020 22:05:05 + From:"Valeriy E. Ushakov" Message-ID: <20200626220505.e9030f...@cvs.netbsd.org> | Modified Files: | src/usr.bin/printf: printf.1 | | Log Message: | Drop redundant quoting in the nested printf example. I don't think that is correct, the quotes around 0x0A were obviously redundant (and changing it to 0x0a doesn't alter that), but those around the $(printf ...) are not - without those the result from the command substitution would be subject to field splitting, and if IFS happens to contain a \ or an octal digit, bad things will happen. In general it is never a good idea to omit quotes around sh word expansions except in the cases where you actually want field splitting (or pathname expansion, etc) to happen (and sometimes except in the contexts where those don't occur anyway, like x=$whatever) For the example in question, try running it with IFS=1 or IFS=2 to see what I mean. kre
Re: CVS commit: src/usr.bin/printf
On Tue, 23 Jul 2019 00:31:32 +0700 Robert Elz wrote: > Date:Mon, 22 Jul 2019 12:23:35 +0200 > From:Tobias Nygren > Message-ID: <20190722122335.55c0d421a18a082c8d67b...@netbsd.org> > > | Please exercise caution when changing established userland behaviour. > | This change broke the pkgsrc/lang/openjdk8(1) build. > > I stand behind my previous reply, if that change seemed to break > anything, then all it was really doing was revealing previous brokenness. > > However, as well as saying that printf(1) has no options, and (by omission) > also saying that it should not do getopt processing, POSIX also says > that if the format arg (ie: the first arg) contains no % cpnversions, > and yet there are more args (which more or less by defnition can never > be used) then the results are unspecified. > > If what is, I am guessing, the "established userland behaviour" was > printf -- format args > which is truly pointless (and incoorrect), but used to be accepted, > then we can continue to allow that to work, relying upon that > unspecified results clause from POSIX, "--" contains no % conversion, > yet there are more args that nothing would normally ever consume > (technically that format string is supposed to be used over and over > again until the args are all used up ... but obviously that would never > happen in this case - which is why it leads to unspecified results). > > I intend to commit a change to printf in a few minutes to make it work > like this (with the caveat that the "no % conversions" test will be "no > % characters" which guarantees no % conversions of course, but is > simpler). > > If there is only one arg, it will always be treated as a format, so > printf ---\\n > will continue working as it should, or if the arg contains a % char, > then it will also be treated as a format, so > printf -%d\\n 3 > will print -3 as it should (neither of those wworked until recently). > > This doesn't mean that whatever script in the openjdk8 build was using > printf incorrectly shouldn't be fixed ... it should still be. > > kre Hi, This sounds like a reasonable compromise in the interest of preserving compatibility with other implementations. Thanks! -Tobias
Re: CVS commit: src/usr.bin/printf
Date:Mon, 22 Jul 2019 12:23:35 +0200 From:Tobias Nygren Message-ID: <20190722122335.55c0d421a18a082c8d67b...@netbsd.org> | Please exercise caution when changing established userland behaviour. | This change broke the pkgsrc/lang/openjdk8(1) build. I stand behind my previous reply, if that change seemed to break anything, then all it was really doing was revealing previous brokenness. However, as well as saying that printf(1) has no options, and (by omission) also saying that it should not do getopt processing, POSIX also says that if the format arg (ie: the first arg) contains no % cpnversions, and yet there are more args (which more or less by defnition can never be used) then the results are unspecified. If what is, I am guessing, the "established userland behaviour" was printf -- format args which is truly pointless (and incoorrect), but used to be accepted, then we can continue to allow that to work, relying upon that unspecified results clause from POSIX, "--" contains no % conversion, yet there are more args that nothing would normally ever consume (technically that format string is supposed to be used over and over again until the args are all used up ... but obviously that would never happen in this case - which is why it leads to unspecified results). I intend to commit a change to printf in a few minutes to make it work like this (with the caveat that the "no % conversions" test will be "no % characters" which guarantees no % conversions of course, but is simpler). If there is only one arg, it will always be treated as a format, so printf ---\\n will continue working as it should, or if the arg contains a % char, then it will also be treated as a format, so printf -%d\\n 3 will print -3 as it should (neither of those wworked until recently). This doesn't mean that whatever script in the openjdk8 build was using printf incorrectly shouldn't be fixed ... it should still be. kre
Re: CVS commit: src/usr.bin/printf
Date:Mon, 22 Jul 2019 12:23:35 +0200 From:Tobias Nygren Message-ID: <20190722122335.55c0d421a18a082c8d67b...@netbsd.org> | This change broke the pkgsrc/lang/openjdk8(1) build. That it is broken and ought to be patched upstream, it is quite clear that printf is required to take no options at all - there was a bug report about it not correctly handling "printf ---" (actually with a newline appended, but that is irrelevant) which it was correct to fix. Sometimes stuff that has relied upon bugs simply breaks when the bugs get fixed. kre
Re: CVS commit: src/usr.bin/printf
On Sun, 21 Jul 2019 15:25:39 + Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Sun Jul 21 15:25:39 UTC 2019 > > Modified Files: > src/usr.bin/printf: printf.c > > Log Message: > Stop assuming that printf handles options in any way at all > (it doesn't - that is, shouldn't) which includes processing -- as an > "end of options". The first arg is (always) the format string. > > Remove call to getopt() (but still do associated changes to argc/argv) > > Note: for now this is #if 0's out instead of being deleted, the old > code should be fully removed sometime soon. > > Problem pointed out on tech-userlevel by Thierry Laronde. Hi! Please exercise caution when changing established userland behaviour. This change broke the pkgsrc/lang/openjdk8(1) build. We can patch it of course but there may be other software out there that expects the old behaviour. (1) https://hg.openjdk.java.net/jdk8u/jdk8u/file/bb03d4e1088a/make/common/MakeBase.gmk#l59 Kind regards, -Tobias
Re: CVS commit: src/usr.bin/printf
Actually, I suspect now that what I remember reading was the rationale in the page in XCU section 4 for the printf command. kre
Re: CVS commit: src/usr.bin/printf
Date:Sun, 27 Jan 2019 18:42:22 +0300 From:Valery Ushakov Message-ID: <20190127154222.gg18...@pony.stderr.spb.ru> | This was changed in Issue 7. The link to the Austin group | interpretations repository seems to be broken, though. Where can I | find the text for the rationale behind this? Sorry, I cannot find it again now - though I read it just a few hours ago (the bug report with the text in it that was adopted)... their search tool for this stuff is worse than pathetic (amongst other things it leads to multiple submissions of the same issue, and even resolutions of issues that contradict the resolution of the same issue when raised earlier - because no-one can ever find anything they're actually looking for.) I will look again tomorrow, but it is more likely to appear when I am looking for something entirely unrelated. kre
Re: CVS commit: src/usr.bin/printf
On Sun, Jan 27, 2019 at 12:03:09 +, Robert Elz wrote: > Modified Files: > src/usr.bin/printf: printf.c > > Log Message: > Revert previous, it was based upon a misreading of the POSIX > spec. POSIX requires "as if by calling strtod()" which we > did already ... by calling strtod(). Go back to doing that. This was changed in Issue 7. The link to the Austin group interpretations repository seems to be broken, though. Where can I find the text for the rationale behind this? -uwe
