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: Unexpected Quick Substitution in string literals
Thanks for the correction on my second example. I had assumed ^ wasn't special inside double quotes since the documentation mentions only the ! character for history expansion ( https://www.gnu.org/software/bash/manual/bash.html#Double-Quotes). However, no character should be treated specially inside single quotes, right? $ echo 'fig ^mango' fig !!:s^mango On Wed, Dec 13, 2023 at 5:54 PM Greg Wooledge wrote: > On Wed, Dec 13, 2023 at 10:50:16AM +0530, Sundeep Agarwal wrote: > > $ echo "fig > > ^mango" > > bash: :s^mango": substitution failed > > I can confirm this happens in every version of bash, at least back to > bash-2.05b which is as far as I can go, but only when history expansion > is enabled (set -H or set -o histexpand). > > I think this is intended behavior, although I'm someone who routinely > disables histexpand, so I'm not as familiar with all of its features as > others might be. >
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
Re: Unexpected Quick Substitution in string literals
On Wed, Dec 13, 2023 at 10:50:16AM +0530, Sundeep Agarwal wrote: > $ echo "fig > ^mango" > bash: :s^mango": substitution failed I can confirm this happens in every version of bash, at least back to bash-2.05b which is as far as I can go, but only when history expansion is enabled (set -H or set -o histexpand). I think this is intended behavior, although I'm someone who routinely disables histexpand, so I'm not as familiar with all of its features as others might be.
Unexpected Quick Substitution in string literals
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux abcd 5.15.0-91-generic #101~20.04.1-Ubuntu SMP Thu Nov 16 14:22:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: While declaring a string literal across multiple lines, a line starting with the ^ character is resulting in some sort of quick substitution processing. I do not have the latest Bash on my machine, but somebody else got the same result on the 5.2.21 version. A string similar to the sample shown below was working as expected 3 years back. If my memory serves right, I had the 4.3 version at that time (on Ubuntu 16 LTS). Repeat-By: $ echo 'fig ^mango' fig !!:s^mango $ echo "fig ^mango" bash: :s^mango": substitution failed Regards, Sundeep
