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 s
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
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
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 q
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 tha
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
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 o
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 variab
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 $(< *fi
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 ind
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 co
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
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
13 matches
Mail list logo
