Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 15/03/2023 00:17, Chet Ramey wrote: On 3/14/23 4:58 PM, Harald van Dijk wrote: On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. Isn't it? The mode bash gets into when invoked as sh is described in the manpage (looking at the 5.2.15 manpage) as: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read. The mode bash gets into when POSIXLY_CORRECT is set, the mode that can also be obtained with --posix, is described in the manpage as: When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. Right. When you force posix mode immediately, as I said above, bash won't read the startup files. A login shell named sh or -sh reads the historical startup fles, then enters posix mode. We are clear on how bash behaves, I believe. What is not clear to me is how I should have worded my message so that you would not have taken issue with it. As far as I can tell, you are saying the same thing I was. I wrote that bash appears to disables the reading of .profile in POSIX mode entirely. It does. I do not see any contradiction between that and what you wrote: while a clarification that this does not apply to bash being invoked as sh or -sh is useful, I made no comment about what happens when bash is invoked as sh or -sh. My comment was about POSIX mode, and when invoked as sh or -sh, per the manpage and your own message, the startup file processing happens while bash is still in non-POSIX mode. So what should I have written instead? If I had written bash appears to disable the reading of .profile in POSIX mode (i.e. bash --posix) entirely. would that have been sufficiently clear to avoid this discussion? If so I will keep that in mind. Cheers, Harald van Dijk
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 3/14/23 4:58 PM, Harald van Dijk wrote: On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. Isn't it? The mode bash gets into when invoked as sh is described in the manpage (looking at the 5.2.15 manpage) as: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read. The mode bash gets into when POSIXLY_CORRECT is set, the mode that can also be obtained with --posix, is described in the manpage as: When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. Right. When you force posix mode immediately, as I said above, bash won't read the startup files. A login shell named sh or -sh reads the historical startup fles, then enters posix mode. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 14/03/2023 20:41, Chet Ramey wrote: On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. Isn't it? The mode bash gets into when invoked as sh is described in the manpage (looking at the 5.2.15 manpage) as: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read. The mode bash gets into when POSIXLY_CORRECT is set, the mode that can also be obtained with --posix, is described in the manpage as: When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup files. My wording appears to be consistent with how bash describes itself in its manpage: there is POSIX mode during startup file processing, and POSIX mode after startup file processing. Only the POSIXLY_CORRECT / --posix behaviour causes startup file processing to happen in POSIX mode, and results in the reading of .profile being disabled. But if I am misunderstanding how you intend for the different modes of bash to be referred to, if you can clarify I can take care to be more careful with my wording in the future. Cheers, Harald van Dijk
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group wrote: bash appears to disables the reading of .profile in POSIX mode entirely. This isn't quite correct. By default, a login shell named `sh' or `-sh' reads /etc/profile and ~/.profile. You can compile bash for `strict posix' conformance, or invoke it with POSIXLY_CORRECT or POSIX_PEDANTIC in the environment, and it won't. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: PDF index^WToC issue
Thorsten Glaser wrote, on 14 Mar 2023: > > I was finally able to obtain 202x_d2.1.pdf (waiting helped), and I found > the index rather lacking. > > Volume 2 chapter 3 and volume 3 chapter 3 comprise thousands of > individual pages; these should be expanded in the index (so one > can find e.g. printf without resorting to the Index at the end. > > Oops, “index”, lowercase, here means table of content in English. I assume you're referring to the "Contents" on pages xiv - xxxi. In a PDF reader if you want to go to the page for printf, the quickest way is to use the PDF index (which is shown in the left hand side bar by all the readers I've ever used). I don't think I have used the "Contents" in the frontmatter to actually find anything in any of the various Issue 7 editions, ever. (I may have for Issue 6, as the PDF index wasn't as complete in those.) -- 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.
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
PDF index^WToC issue
Hi, I was finally able to obtain 202x_d2.1.pdf (waiting helped), and I found the index rather lacking. Volume 2 chapter 3 and volume 3 chapter 3 comprise thousands of individual pages; these should be expanded in the index (so one can find e.g. printf without resorting to the Index at the end. Oops, “index”, lowercase, here means table of content in English. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
