Documentation Bug: ‘of’ should be ‘or’
As of Reference Documentation for Bash Edition 5.2, for Bash Version 5.2. September 2022 In 3.1.2.5 Locale-Specific Translation Quoting from the first paragraph of this section: If the current locale is C or POSIX, if there are no translations available, of if the string is not translated, the dollar sign is ignored. This sentence should read: If the current locale is C or POSIX, if there are no translations available, or if the string is not translated, the dollar sign is ignored.
Re: Documentation Bug: ‘of’ should be ‘or’
+1 On Sun, Mar 17, 2024, 15:04 Abigail Read wrote: > As of > Reference Documentation for Bash Edition 5.2, for Bash Version 5.2. > September 2022 > > In 3.1.2.5 Locale-Specific Translation > Quoting from the first paragraph of this section: > If the current locale is C or POSIX, if there are no translations > available, of if the string is not translated, the dollar sign is ignored. > > This sentence should read: > If the current locale is C or POSIX, if there are no translations > available, or if the string is not translated, the dollar sign is ignored.
Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi
Bash Maintainers,
The texinfo version of the bash manual is missing a description of
the ‘shopt’ option ‘syslog_history’. This can be confirmed by
downloading bash-master.tar.gz from:
http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz
Searching the file bash-master/doc/bashref.texi gives no instance of
"syslog" or "syslog_history". An entry for ‘syslog_history’ is provided
in the ‘man’ page for ‘bash’:
syslog_history
If set, command history is logged to syslog.
To match the ‘man’ page for ‘bash’, an entry should be added to
‘bashref.texi’ between the following two entries (which start at line
5900 in the file):
> @item varredir_close
> If set, the shell automatically closes file descriptors assigned using the
> @code{@{varname@}} redirection syntax (@pxref{Redirections}) instead of
> leaving them open when the command completes.
>
> @item xpg_echo
> If set, the @code{echo} builtin expands backslash-escape sequences
> by default.
This would then match the non-alphabetical ordering of the ‘shopts’
options in the ‘man’ page.
A better solution would be to fix the non-alphabetical ordering in the
‘man’ page (move ‘syslog_history’ entry before the ‘varredir_close’
entry) and add a matching entry to ‘bashref.texi’ in the alphabetically
correct ordering.
--
Re: Examples of concurrent coproc usage?
On Thu, Mar 14, 2024 at 6:57 AM Carl Edquist wrote: > (And in general, latter coproc shells will have stray copies of the user > shell's r/w ends from all previous coprocs.) I didn't know that without MULTIPLE_COPROCS=1, bash wouldn't even attempt to keep the fds from earlier coprocs out of later coprocs. > Unexpectedly, the new multi-coproc code seems to close the user shell's > end of a coprocess's pipes, once the coprocess has terminated. When > compiled with MULTIPLE_COPROCS=1, this is true even if there is only a > single coproc: > This is a bug. The shell should not automatically close its read pipe to > a coprocess that has terminated -- it should stay open to read the final > output, and the user should be responsible for closing the read end > explicitly. > It also invites trouble if the shell variable that holds the fds gets > removed unexpectedly when the coprocess terminates. (Suddenly the > variable expands to an empty string.) It seems to me that the proper time > to clear the coproc variable (if at all) is after the user has explicitly > closed both of the fds. *Or* else add an option to the coproc keyword to > explicitly close the coproc - which will close both fds and clear the > variable. I agree. This was the discussion in [1], where it sounds like this was the intended behavior. The array that bash originally created to store the coproc fds is removed immediately, but the fds are evidently closed at some later, indeterminate point. So, if you store the coproc fds in a different array than the one bash gave you, you might still be able to read from the read fd for a little while. That sounds suspiciously like a race condition, though. The behavior without MULTIPLE_COPROCS=1 might have changed since that discussion. > That's a nice trick with the shell backgrounding all the coprocesses > before connecting the fifos. But yeah, to make subsequent coprocesses you > do still have to close the copy of the user shell's fds that the coprocess > shell inherits. It sounds like you are doing that (nice!), but in any > case it requires some care, and as these stack up it is really handy to > have something manage it all for you. I absolutely learned more about what I was doing from that conversation with Chet three years ago. > (Perhaps this is where I ask if you are happy with your solution or if you > would like to try out something wildly more flexible...) Admittedly, I am very curious to see your bash coprocess management library. I don't know how you could implement coprocesses outside of bash's coproc keyword without using FIFOs somehow. > Happy coprocessing! :) Thanks for your detailed description of all this. [1] https://lists.gnu.org/archive/html/help-bash/2021-04/msg00136.html
Re: Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi
On Sunday, March 17, 2024, tpeplt wrote: > >The texinfo version of the bash manual is missing a description of > the ‘shopt’ option ‘syslog_history’. > That must be a vendor extension, bash doesn't have such an option. -- Oğuz
Re: Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi
On Mon, 18 Mar 2024 06:30:49 +0200 Oğuz wrote: > On Sunday, March 17, 2024, tpeplt wrote: > > > >The texinfo version of the bash manual is missing a description of > > the ‘shopt’ option ‘syslog_history’. > > > > That must be a vendor extension, bash doesn't have such an option. It has such an option in the case that SYSLOG_HISTORY and SYSLOG_SHOPT are defined. -- Kerin Millar
Re: Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi
On Mon, Mar 18, 2024, at 12:49 AM, Kerin Millar wrote: > On Mon, 18 Mar 2024 06:30:49 +0200 > Oğuz wrote: > >> On Sunday, March 17, 2024, tpeplt wrote: >> > >> >The texinfo version of the bash manual is missing a description of >> > the ‘shopt’ option ‘syslog_history’. >> > >> >> That must be a vendor extension, bash doesn't have such an option. > > It has such an option in the case that SYSLOG_HISTORY and SYSLOG_SHOPT > are defined. I doubt those cause the build to modify the documentation, though. The packager must have edited the man page. -- vq
