Re: behavior of printf '\x61'

2021-04-15 Thread Philip Guenther via austin-group-l at The Open Group
Correction after off-list poke: FreeBSD's /usr/bin/printf and the printf builtin to /bin/sh both show "x61" On Thu, Apr 15, 2021 at 7:04 PM Philip Guenther wrote: > The general question is what requirements the standard put on the printf > utility when the format argument contains a \x or other

Re: behavior of printf '\x61'

2021-04-15 Thread shwaresyst via austin-group-l at The Open Group
It is covered in Item 7 of those 11 exceptions, 'x' falling under the blanket "every character not specified is unspecified". Portable code is expected to use the work alike octal escape, not hex codes. On Fri, Apr 16, 2021 at 12:05 AM, Philip Guenther via austin-group-l at The Open Group

Re: behavior of printf '\x61'

2021-04-15 Thread Oğuz via austin-group-l at The Open Group
16 Nisan 2021 Cuma tarihinde Philip Guenther via austin-group-l at The Open Group yazdı: > > Did I miss a statement about somewhere that renders this > behavior unspecified? > P1003.1™-202x/D1.1 Page 3036, Line 102784: > The interpretation of a followed by any other sequence of characters is

behavior of printf '\x61'

2021-04-15 Thread Philip Guenther via austin-group-l at The Open Group
The general question is what requirements the standard put on the printf utility when the format argument contains a \x or other unspecified backslash escape, but the example in the subject is a nice concrete example: what's required for or about the output of printf '\x61' ? 1003.1-2016

Re: execve(2) optimisation for last command

2021-04-15 Thread Harald van Dijk via austin-group-l at The Open Group
On 15/04/2021 21:36, Martijn Dekker via austin-group-l at The Open Group wrote: My question: why is this? I would have thought that a script is a script and that it should make no essential difference whether a script is taken from a -c argument or loaded from a file. What makes the

Re: execve(2) optimisation for last command

2021-04-15 Thread Chet Ramey via austin-group-l at The Open Group
On 4/15/21 4:36 PM, Martijn Dekker via austin-group-l at The Open Group wrote: Most shells 'exec' the last command in -c scripts, e.g.: However, no shell seems to do this for scripts loaded from a file: My question: why is this? I would have thought that a script is a script and that

execve(2) optimisation for last command

2021-04-15 Thread Martijn Dekker via austin-group-l at The Open Group
Most shells 'exec' the last command in -c scripts, e.g.: $ bash -c 'printf "$$ "; sh -c "echo \$\$"' 66303 66303 $ dash -c 'printf "$$ "; sh -c "echo \$\$"' 66304 66304 $ ksh93 -c 'printf "$$ "; sh -c "echo \$\$"' 66305 66305 $ yash -c 'printf "$$ "; sh -c "echo \$\$"' 66309 66309 $ zsh -c

[1003.1(2013)/Issue7+TC1 0000713]: in remquo quo should be unspecified when the result is NaN

2021-04-15 Thread Austin Group Bug Tracker via austin-group-l at The Open Group
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=713 == Reported By:nsz Assigned To:

Defect 1272 (':' command) poor language

2021-04-15 Thread Robert Elz via austin-group-l at The Open Group
I just noticed (you really don't want to know the chain of thought that got me here!) that when bug 1272 was applied, some non-ideal language was added in the CHANGE HISTORY section for Issue 8. (This is in XCU 2.14, Special Built-in Utilities ("colon") on page 2316 of draft 1.1 of issue 8)

[1003.1(2013)/Issue7+TC1 0000713]: in remquo quo should be unspecified when the result is NaN

2021-04-15 Thread Austin Group Bug Tracker via austin-group-l at The Open Group
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=713 == Reported By:nsz Assigned To: