Re: funsub questions
On 12/17/23 10:47 PM, Zachary Santer wrote: As a follow-on question, why would this be implemented only now? From the very beginning, capturing the stdout of an external command involved forking a subshell, and soon (assuming funsubs remain when 5.3 is released) it won't have to. It feels like something changed to make this feasible when it hadn't been before. I suppose it was mostly the work I did to make command substitution parsing call the bison parser recursively instead of using the ad-hoc scheme that had been in place for years. Once you identify all the relevant parser state, the alternate nofork command substitution becomes easier. Time and motivation are always factors, of course. -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: funsub questions
On Wed, Dec 13, 2023 at 9:29 PM Kerin Millar wrote: > On Wed, 13 Dec 2023 20:50:48 -0500 > Zachary Santer wrote: > > Would using funsubs to capture the stdout of external commands be > > appreciably faster than using comsubs for the same? > > In the case of a script that would otherwise fork many times, frequently, the difference is appreciable and can be easily measured. As a follow-on question, why would this be implemented only now? From the very beginning, capturing the stdout of an external command involved forking a subshell, and soon (assuming funsubs remain when 5.3 is released) it won't have to. It feels like something changed to make this feasible when it hadn't been before. Zack
Re: funsub questions
On Thu, Dec 14, 2023 at 04:44:07AM +, Kerin Millar wrote: > On Wed, 13 Dec 2023 23:16:11 -0500 > Zachary Santer wrote: > > > On Wed, Dec 13, 2023 at 11:06 PM Greg Wooledge wrote: > > > Is that on a system that lacks a process manager? Something like > > > "systemctl reload ssh" or "service ssh reload" would be preferred from > > > a system admin POV, on systems that have process managers. > > I am not super knowledgeable in this kind of stuff, but would that not > > cause you to lose your SSH connection? > > It would not. Nor would even a restart, owing to the way privilege separation > is implemented in sshd(8). To expand on this: in most process managers used on Linux systems, the "reload" action sends a SIGHUP or equivalent, if the service supports it. The "restart" action stops and then starts the service. sshd is a special case, with each active connection being managed by a child of the main daemon. Stopping and restarting the main daemon does not cause the existing children to be terminated. This was true even before privilege separation was added.
Re: funsub questions
On Dez 13 2023, Greg Wooledge wrote: > If you'd like to read the contents of a file into a variable, the > "read" and "readarray" (aka "mapfile") builtins are usually better > choices anyway. $(< file) would only be useful if you want the entire > content in a single string variable, which is a questionable idea in > most programs. For interactive use, $(< ...) is convenient and less verbose than the alternatives. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: funsub questions
On Wed, 13 Dec 2023 23:16:11 -0500 Zachary Santer wrote: > On Wed, Dec 13, 2023 at 11:06 PM Greg Wooledge wrote: > > Is that on a system that lacks a process manager? Something like > > "systemctl reload ssh" or "service ssh reload" would be preferred from > > a system admin POV, on systems that have process managers. > I am not super knowledgeable in this kind of stuff, but would that not > cause you to lose your SSH connection? It would not. Nor would even a restart, owing to the way privilege separation is implemented in sshd(8). -- Kerin Millar
Re: funsub questions
On Wed, Dec 13, 2023 at 11:06 PM Greg Wooledge wrote: > Is that on a system that lacks a process manager? Something like > "systemctl reload ssh" or "service ssh reload" would be preferred from > a system admin POV, on systems that have process managers. I am not super knowledgeable in this kind of stuff, but would that not cause you to lose your SSH connection? > And before bash 5.2, > > read -r pid < /var/run/sshd.pid && sudo kill -s SIGHUP "$pid" > > would be more efficient, on systems where no process manager is in use. Yeah, that's fair. This is in the interactive shell, though, so how long it takes to run isn't a huge concern.
Re: funsub questions
On Wed, Dec 13, 2023 at 10:48:59PM -0500, Zachary Santer wrote: > On Wed, Dec 13, 2023 at 9:17 PM Greg Wooledge wrote: > > If you'd like to read the contents of a file into a variable, the > > "read" and "readarray" (aka "mapfile") builtins are usually better > > choices anyway. $(< file) would only be useful if you want the entire > > content in a single string variable, which is a questionable idea in > > most programs. > sudo kill -s SIGHUP "$(< /var/run/sshd.pid)" > The one thing I've done with this that wasn't a bad idea. Is that on a system that lacks a process manager? Something like "systemctl reload ssh" or "service ssh reload" would be preferred from a system admin POV, on systems that have process managers. And before bash 5.2, read -r pid < /var/run/sshd.pid && sudo kill -s SIGHUP "$pid" would be more efficient, on systems where no process manager is in use.
Re: funsub questions
On Wed, Dec 13, 2023 at 9:17 PM Greg Wooledge wrote: > If you'd like to read the contents of a file into a variable, the > "read" and "readarray" (aka "mapfile") builtins are usually better > choices anyway. $(< file) would only be useful if you want the entire > content in a single string variable, which is a questionable idea in > most programs. sudo kill -s SIGHUP "$(< /var/run/sshd.pid)" The one thing I've done with this that wasn't a bad idea.
Re: funsub questions
On Thu, Dec 14, 2023 at 02:39:04AM +, Kerin Millar wrote:
> On Wed, 13 Dec 2023 21:17:05 -0500
> Greg Wooledge wrote:
>
> > On Wed, Dec 13, 2023 at 08:50:48PM -0500, Zachary Santer wrote:
> > > Would there be a purpose in implementing ${< *file*; } to be the
> > > equivalent
> > > of $(< *file* )? Does $(< *file* ) itself actually fork a subshell?
> >
> > $(< file) does indeed fork. The only difference between $(< file) and
> > $(cat file) is the latter also does an exec (but it's portable).
>
> This stopped being the case with the release of 5.2 or thereabouts.
unicorn:~$ strace -e clone bash-5.1 -c ': $(< /etc/profile)'
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f274f5cba10) = 105452
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=105452, si_uid=1000,
si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++
unicorn:~$ strace -e clone bash-5.2 -c ': $(< /etc/profile)'
+++ exited with 0 +++
Huh... so it seems. OK then.
Re: funsub questions
On Wed, 13 Dec 2023 21:17:05 -0500
Greg Wooledge wrote:
> On Wed, Dec 13, 2023 at 08:50:48PM -0500, Zachary Santer wrote:
> > Would there be a purpose in implementing ${< *file*; } to be the equivalent
> > of $(< *file* )? Does $(< *file* ) itself actually fork a subshell?
>
> $(< file) does indeed fork. The only difference between $(< file) and
> $(cat file) is the latter also does an exec (but it's portable).
This stopped being the case with the release of 5.2 or thereabouts.
--
Kerin Millar
Re: funsub questions
On Wed, 13 Dec 2023 20:50:48 -0500
Zachary Santer wrote:
> Would there be a purpose in implementing ${< *file*; } to be the equivalent
> of $(< *file* )? Does $(< *file* ) itself actually fork a subshell?
No, $(< file) does not fork.
>
> Would using funsubs to capture the stdout of external commands be
> appreciably faster than using comsubs for the same?
In the case of a script that would otherwise fork many times, frequently, the
difference is appreciable and can be easily measured. However, scripts of that
nature sometimes benefit from being written in a way that does not involve
comsubs. Therefore, I would place a greater value on the elimination of
gratuitous comsubs, where possible, than to merely replace all of them with
funsubs (notwithstanding that 5.3 has yet to be released).
--
Kerin Millar
Re: funsub questions
On Wed, Dec 13, 2023 at 08:50:48PM -0500, Zachary Santer wrote:
> Would there be a purpose in implementing ${< *file*; } to be the equivalent
> of $(< *file* )? Does $(< *file* ) itself actually fork a subshell?
$(< file) does indeed fork. The only difference between $(< file) and
$(cat file) is the latter also does an exec (but it's portable).
If you'd like to read the contents of a file into a variable, the
"read" and "readarray" (aka "mapfile") builtins are usually better
choices anyway. $(< file) would only be useful if you want the entire
content in a single string variable, which is a questionable idea in
most programs.
funsub questions
Would there be a purpose in implementing ${< *file*; } to be the equivalent
of $(< *file* )? Does $(< *file* ) itself actually fork a subshell?
Would using funsubs to capture the stdout of external commands be
appreciably faster than using comsubs for the same?
- Zack
