[1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1640 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1640 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: Applied Name: Robert Elz Organization: User Reference: Section:XCU 3 / true Page Number:3318 Line Number:111745 - 111748 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1640#c6206 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-03-12 07:00 UTC Last Modified: 2023-05-16 11:09 UTC == Summary:The rationale given for retaining "true" is nonsense. == Issue History Date ModifiedUsername FieldChange == 2023-03-12 07:00 kreNew Issue 2023-03-12 07:00 kreName => Robert Elz 2023-03-12 07:00 kreSection => XCU 3 / true 2023-03-12 07:00 krePage Number => 3318 2023-03-12 07:00 kreLine Number => 111745 - 111748 2023-03-12 16:54 stephane Note Added: 0006202 2023-03-16 15:54 geoffclare Note Added: 0006206 2023-03-16 15:55 geoffclare Interp Status => --- 2023-03-16 15:55 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1640#c6206 2023-03-16 15:55 geoffclare Status New => Resolved 2023-03-16 15:55 geoffclare Resolution Open => Accepted As Marked 2023-03-16 15:55 geoffclare Tag Attached: tc3-2008 2023-05-16 11:09 geoffclare Status Resolved => Applied ==
[1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1640 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1640 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: Resolved Name: Robert Elz Organization: User Reference: Section:XCU 3 / true Page Number:3318 Line Number:111745 - 111748 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1640#c6206 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-03-12 07:00 UTC Last Modified: 2023-03-16 15:55 UTC == Summary:The rationale given for retaining "true" is nonsense. == Issue History Date ModifiedUsername FieldChange == 2023-03-12 07:00 kreNew Issue 2023-03-12 07:00 kreName => Robert Elz 2023-03-12 07:00 kreSection => XCU 3 / true 2023-03-12 07:00 krePage Number => 3318 2023-03-12 07:00 kreLine Number => 111745 - 111748 2023-03-12 16:54 stephane Note Added: 0006202 2023-03-16 15:54 geoffclare Note Added: 0006206 2023-03-16 15:55 geoffclare Interp Status => --- 2023-03-16 15:55 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1640#c6206 2023-03-16 15:55 geoffclare Status New => Resolved 2023-03-16 15:55 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1640 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1640 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 3 / true Page Number:3318 Line Number:111745 - 111748 Interp Status: --- Final Accepted Text: == Date Submitted: 2023-03-12 07:00 UTC Last Modified: 2023-03-16 15:54 UTC == Summary:The rationale given for retaining "true" is nonsense. == -- (0006206) geoffclare (manager) - 2023-03-16 15:54 https://austingroupbugs.net/view.php?id=1640#c6206 -- On page 3317 line 111737 section true (APPLICATION USAGE), change:The special built-in utility : is sometimes more efficient than true.to:Although the special built-in utility : (colon) is similar to true, there are some notable differences, including: Whereas colon is required to accept, and do nothing with, any number of arguments, true is only required to accept, and discard, a first argument of "--". Passing any other argument(s) to true may cause its behavior to differ from that described in this standard. A non-interactive shell exits when a redirection error occurs with colon (unless executed via command), whereas with true it does not. Variable assignments preceding the command name persist after executing colon (unless executed via command), but not after executing true. In shell implementations where true is not provided as a built-in, using colon avoids the overheads associated with executing an external utility. On page 3318 line 111746 section true, replace the contents of RATIONALE with:None. On page 3318 line 111752 section true, add colon and command to SEE ALSO. On page 2389 line 76461 section colon, change APPLICATION USAGE from:None.to:See the APPLICATION USAGE for true. On page 2390 line 76479 section colon, add true to SEE ALSO. Issue History Date ModifiedUsername FieldChange == 2023-03-12 07:00 kreNew Issue 2023-03-12 07:00 kreName => Robert Elz 2023-03-12 07:00 kreSection => XCU 3 / true 2023-03-12 07:00 krePage Number => 3318 2023-03-12 07:00 kreLine Number => 111745 - 111748 2023-03-12 16:54 stephane Note Added: 0006202 2023-03-16 15:54 geoffclare Note Added: 0006206 ==
Re: [1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
Date:Tue, 14 Mar 2023 10:31:52 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: | I think this and some other differences between ":" and "true" are | worth mentioning in the standard. I don't think that would do any harm, or is incorrect, but I'm not sure it is necessary either. Some of us recognise that true and : are (in many uses) more or less interchangeable. That doesn't mean that we need to explain why both exist, or what the differences are. It is often possible to replace grep with sed - the standard does not need to say that, or explain how, or what grep can do that is not so easy using sed. Same here. Just removing the Rationale would be enough, but I don't mind if you really believe the rest of this is needed. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
Stephane Chazelas wrote, on 12 Mar 2023:
>
> true "$var"
>
> is not POSIX and *in practice not portable* as at least one
> implementation (GNU) doesn't ignore its arguments (and
> toybox/busybox don't ignore argv[0]), so true can't be used in
> place of : for things like:
>
> : "${QUERYSTRING-$1}"
>
> or:
>
> : "$(( i -= 1 ))"
>
> printf '' or command : could be used if the point is to avoid
> the specialness of ":".
I think this and some other differences between ":" and "true" are
worth mentioning in the standard.
Here's my suggestion...
On page 3317 line 111737 section true (APPLICATION USAGE), change:
The special built-in utility : is sometimes more efficient than
true.
to:
Although the special built-in utility : (colon) is
similar to true, there are some notable differences:
Whereas colon is required to accept, and do nothing with,
any number of arguments, true is only required to accept, and
discard, a first argument of "--". Passing any other argument(s) to
true may cause its behavior to differ from that described in
this standard.
A non-interactive shell exits when a redirection error occurs
with colon (unless executed via command), whereas with
true it does not.
Variable assignments preceding the command name persist after
executing colon (unless executed via command), but not
after executing true.
In shell implementations where true is not provided as a
built-in, using colon avoids the overheads associated with
executing an external utility.
On page 3318 line 111746 section true, replace the contents of RATIONALE with:
None.
On page 3318 line 111752 section true, add colon and command
to SEE ALSO.
On page 2389 line 76461 section colon, change APPLICATION USAGE from:
None.
to:
See the APPLICATION USAGE for true.
On page 2390 line 76479 section colon, add true to SEE ALSO.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
2023-03-12 14:04:55 -0400, Lawrence Velázquez via austin-group-l at The Open
Group:
[...]
> > What happens (exit status etc) if there's a write error while writing that
> > output?
>
> % /opt/local/libexec/gnubin/true --version >&-; echo "$?"
> true: write error: Bad file descriptor
> 1
>
> Interestingly, the documentation anticipates this concern:
> https://www.gnu.org/software/coreutils/manual/html_node/true-invocation.html
[...]
In any case a command can exit with a non-zero status for all
sorts of pathological cases like when:
- it's not invoked as meant to (here as far as POSIX is
concerned if given any argument other than --).
- it fails to allocate memory
- it runs out of stack size
- the dynamic linker can't find some dependencies, or is told to
load the wrong ones (LD_LIBRARY_PATH, LD_PRELOAD, LD_DEBUG...)
- it's killed (including from reaching some limits, writing to
a closed pipe/socket...)
- fails to decode its arguments as text. Here, - being part of
the portable character set and should be single byte and
invariant across locales (or is it?), there's no reason why a
true that doesn't implement extensions over the standard want
to decode its args as text but one that does might.
- for the above, the LC_* variable and locale processing could
trigger errors.
- and likely plenty other reasons I'm not thinking of why it may
fail. Consider that some implementations like busybox' are
toybox' are quite complex. For instance busybox' true will do
something else if passed a argv[0] that is not true or doesn't
end in /true.
But the takeaway here is that:
true "$var"
is not POSIX and *in practice not portable* as at least one
implementation (GNU) doesn't ignore its arguments (and
toybox/busybox don't ignore argv[0]), so true can't be used in
place of : for things like:
: "${QUERYSTRING-$1}"
or:
: "$(( i -= 1 ))"
printf '' or command : could be used if the point is to avoid
the specialness of ":". Or redefine true as:
true() { : ; }
Or:
true() case for in esac
or even:
true() { command true; }
--
Stephane
Re: [1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
Thanks, I think that's all we needed to know about what it does. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
On Sun, Mar 12, 2023, at 1:35 PM, Robert Elz via austin-group-l at The Open Group wrote: > With the GNU version, what would be more interesting to know, is what > it does when run as > true --nonsense > true -- > true '--:) (-;' > (and similar). What's the exit status, is there any output, and if > so, to stdout or stderr? % /opt/local/libexec/gnubin/true --nonsense; echo "$?" 0 % /opt/local/libexec/gnubin/true --; echo "$?" 0 % /opt/local/libexec/gnubin/true '--:) (-;'; echo "$?" 0 > I'm also assuming that the --version and --help (to be meaningful "accepted" > rather than just ignored - everyone's true allows and ignores those, and > any other args given) actually produce some output. stdout or stderr? They print messages to stdout. > What happens (exit status etc) if there's a write error while writing that > output? % /opt/local/libexec/gnubin/true --version >&-; echo "$?" true: write error: Bad file descriptor 1 Interestingly, the documentation anticipates this concern: https://www.gnu.org/software/coreutils/manual/html_node/true-invocation.html -- vq
Re: [1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
Date:Sun, 12 Mar 2023 16:54:34 + From:Austin Group Bug Tracker Message-ID: <0a945390fc5d0c6c366071bcd2d29...@austingroupbugs.net> | A NOTE has been added to this issue. I don't think this discussion needs to be in notes, or not unless something relevant to the actual issue itself is revealed. | GNU true accepts some --version, --help options. That is perhaps not surprising - weird though, as if true was going to need multiple versions to get it right, or add features, or that anyone needs help writing "true" ...But OK, and apart from one potential issue (later). | I don't have access to ksh93 just now but I'd expect its true to supports | those as well as --author --man --usage and many more in that vein like | most of its builtins do. Not that I can see, it appears to ignore any operands to true, just as (almost) everyone else's (and all sane) versions do. With the GNU version, what would be more interesting to know, is what it does when run as true --nonsense true -- true '--:) (-;' (and similar). What's the exit status, is there any output, and if so, to stdout or stderr? I'm also assuming that the --version and --help (to be meaningful "accepted" rather than just ignored - everyone's true allows and ignores those, and any other args given) actually produce some output. stdout or stderr? What happens (exit status etc) if there's a write error while writing that output? kre
[1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1640 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1640 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 3 / true Page Number:3318 Line Number:111745 - 111748 Interp Status: --- Final Accepted Text: == Date Submitted: 2023-03-12 07:00 UTC Last Modified: 2023-03-12 16:54 UTC == Summary:The rationale given for retaining "true" is nonsense. == -- (0006202) stephane (reporter) - 2023-03-12 16:54 https://austingroupbugs.net/view.php?id=1640#c6202 -- GNU true accepts some --version, --help options. I don't have access to ksh93 just now but I'd expect its true to supports those as well as --author --man --usage and many more in that vein like most of its builtins do. Issue History Date ModifiedUsername FieldChange == 2023-03-12 07:00 kreNew Issue 2023-03-12 07:00 kreName => Robert Elz 2023-03-12 07:00 kreSection => XCU 3 / true 2023-03-12 07:00 krePage Number => 3318 2023-03-12 07:00 kreLine Number => 111745 - 111748 2023-03-12 16:54 stephane Note Added: 0006202 ==
[1003.1(2016/18)/Issue7+TC2 0001640]: The rationale given for retaining "true" is nonsense.
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1640 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1640 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XCU 3 / true Page Number:3318 Line Number:111745 - 111748 Interp Status: --- Final Accepted Text: == Date Submitted: 2023-03-12 07:00 UTC Last Modified: 2023-03-12 07:00 UTC == Summary:The rationale given for retaining "true" is nonsense. Description: The RATIONALE section of the page for the "true" utility says: The true utility has been retained in this volume of POSIX.1-2017, even though the shell special built-in : provides similar functionality, because true is widely used in historical scripts and is less cryptic to novice script readers. That text remains unchanged in Issue 8 draft 2.1 The functionality is only vaguely similar, true is a normal utility, ':' is a special builtin, hence the consequences of redirection errors are different, and use, redirections are used with these utilities. Further, the OPERANDS listed for "true" are "None" which XCU 1.4 says means "When this section is listed as ``None.'', it means that the implementation need not support any operands.", which allows an implementation to do things with operands if it wants, including issueing an error message failing (turning info "false"). While none do, that I am aware of (true is generally, and entirely, "exit 0" or "exit(0)" in C) it is possible. Finally, since this bug is being submitted against Issue 7 TC2, XCU 2.9.1.1 bullet point 'd' says: If the command name matches the name of the type or ulimit utility, or of a utility listed in the following table, that utility shall be invoked. Note "shall be invoked" and "true" is in the table. If there were no "true" utility, that would be impossible, so deleting true really could not have happened (back then) no matter how redundant it seemed to be. Note that in Issue 8 draft 2.1, this has altered, it is now 2.9.1.4 (still bullet point d) but that now refers to the intrinsic utilities defined in XCU 1.7, and "true" is not in that list. Desired Action: Delete the entire RATIONAL section (lines 111746 - 111748) and replace them with None. == Issue History Date ModifiedUsername FieldChange == 2023-03-12 07:00 kreNew Issue 2023-03-12 07:00 kreName => Robert Elz 2023-03-12 07:00 kreSection => XCU 3 / true 2023-03-12 07:00 krePage Number => 3318 2023-03-12 07:00 kreLine Number => 111745 - 111748 ==
