On 9/18/25 10:09 AM, Koichi Murase wrote:
2025年8月29日(金) 20:16 Kevin Pulo :
This patch adds the syntax ${;cmd;}, which is handled identically to ${ cmd;}
except that trailing newlines are preserved.
I've checked the contents of the patch. Maybe it's already been
applied to the codebase with adj
2025年8月29日(金) 20:16 Kevin Pulo :
> This patch adds the syntax ${;cmd;}, which is handled identically to ${ cmd;}
> except that trailing newlines are preserved.
I've checked the contents of the patch. Maybe it's already been
applied to the codebase with adjustments, but shouldn't the
keep-trailing-
2025年9月4日(木) 20:57 Martin D Kealey :
> On Wed, 3 Sept 2025 at 07:17, Koichi Murase wrote:
>> 2025年9月3日(水) 1:21 Martin D Kealey :
>> > Maybe « function foo -o compat=60 -o extglob -o nullglob … { …; } »?
>>
>> With that syntax, Zsh defines multiple functions of the same content,
>
> Aww sheesh. Zsh
On 9/15/25 11:03 PM, Kevin Pulo wrote:
On Tue, 9 Sept 2025 at 00:05, Chet Ramey wrote:
That association seems kind of tenuous, but it's better than nothing.
Attached is a patch for suggested docs and tests updates, to go alongside the
original ${;cmd;} patch. Shouldn't be too hard to update
#x27;1 == 1'
: ${ let '1 == 1'; }
+: "${;let '1 == 1'; }"
set +o posix ; shopt -s expand_aliases
diff --git a/tests/comsub23.sub b/tests/comsub23.sub
index 5c90d513..0f251a46 100644
--- a/tests/comsub23.sub
+++ b/tests/comsub23.sub
@@ -17,15 +17,21 @@
# make sur
On 9/8/25 4:19 AM, Kevin Pulo wrote:
On Sun, 7 Sept 2025 at 12:40, Koichi Murase wrote:
I'd associate `;' with something related to the end, which has some affinity
with the current feature of preserving newlines at the end of the command
output.
I think I was (subconsciously) thinking along
On 9/6/25 8:14 AM, Martin D Kealey wrote:
Are we allowed to venture into the realm of UTF-8?
No, the shell has to work in non-UTF-8 locales without asking too much of
the user.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippoc
, and even if
there were it would probably be ${parameter@n} to _actually_ strip trailing
newlines. It could also introduce confusion by suggesting that the other
existing parameter transformations could be used, eg. ${@U cmd ;}, which isn't
the case, at least not without a lot of extra wor
I vote for ${; cmd; }. It now seems to make sense to me. It initially
appeared to be strange, but it seems to be a matter of whether you've
gotten used to it. We already have ${| cmd; }, and there are still
many command delimiters (where `|' belongs to), such as `&', `;',
`||', `&&', `|&', `;;', `;
On Sat, 6 Sept 2025 at 06:43, Chet Ramey wrote:
> Anyone else have candidates for the command character?
>
How about if the lead character is newline?
${
*commands*
}
(Ordinarily I wouldn't suggest re-purposing “existing” syntax, but this
feature has only existed for a brief while, so perhaps
On 8/29/25 7:15 AM, Kevin Pulo wrote:
On Fri, 29 Aug 2025 at 01:00, Koichi Murase wrote:
If the feature is really desired by the community as an essential feature, it
should be implemented as a new syntax.
I looked at adding alternate syntax for doing command substitution without
stripping
On Wed, 3 Sept 2025 at 07:17, Koichi Murase wrote:
> 2025年9月3日(水) 1:21 Martin D Kealey :
> > I really like this approach, but I suspect it will lead to a need
> > for something akin to Perl's "use" or "BEGIN" keywords to execute
> > code as soon as they're fully parsed, even if the encoding block
2025年8月29日(金) 20:16 Kevin Pulo :
> On Fri, 29 Aug 2025 at 01:00, Koichi Murase wrote:
> > If the feature is really desired by the community as an essential feature,
> > it
> > should be implemented as a new syntax.
>
> I looked at adding alternate syntax for doing c
2025年9月3日(水) 1:21 Martin D Kealey :
> I really like this approach, but I suspect it will lead to a need
> for something akin to Perl's "use" or "BEGIN" keywords to execute
> code as soon as they're fully parsed, even if the encoding block
> hasn't finished parsing.
>
> Then we could write something
On Tue, 2 Sep 2025, 23:45 Koichi Murase, wrote:
> I think, if an option to change the language behavior would be
> introduced, the option should be implemented as ``a file-local option
> that applies to shell codes based on lexical scoping''.
>
I really like this approach, but I suspect it will
2025年8月31日(日) 0:45 Stan Marsh :
> However, it does still leave the problem that whatever objections they have
> had to the
> idea of doing it with "shopt" applies to pretty much most/all of the (other)
> "shopt"
> options. That is, most/all of the "shopt" options change shell behavior in
> ways
On Fri, 29 Aug 2025 at 01:00, Koichi Murase wrote:
> If the feature is really desired by the community as an essential feature, it
> should be implemented as a new syntax.
I looked at adding alternate syntax for doing command substitution without
stripping trailing newlines, and it turn
>> If the feature is really desired by the community as an essential feature, it
>> should be implemented as a new syntax.
>I looked at adding alternate syntax for doing command substitution without
>stripping trailing newlines, and it turned out to be easier than I expected.
| preserve)$(bar | preserve)$(baz | preserve)"
(for some hypothetical "preserve" function that somehow preserved trailing
newlines) then that would be also a lot better.
> > This could be done by piping into an ugly sed/awk program, [...] Also note
> > that, AFAIK, the revers
2025年8月28日(木) 17:29 Martin D Kealey :
> On Wed, 27 Aug 2025 at 15:16, Koichi Murase wrote:
>> local saved=$(shopt -p cmdsubst_trailing_nls) # (assume we are in a
>> function)
>> shopt -s cmdsubst_trailing_nls
>> foo=$(some_command ...)
>> eval -- "$saved"
>
> Couldn't we just dictate that
e the behavior at the side of the command
inside $(), isn't it easier to modify the commands that want to
preserve the trailing newlines so that they output an extra `.',
allowing to simply call it as « foo=$(cmd); x=${x%.} »? Since the CLI
tools are basically designed to be line-orien
On Thursday, August 28, 2025, Kevin Pulo wrote:
>
> I have a lot of control
Good. It's easier to change the input than change Bash and wait for another
release (which might take more than a year).
> I could instead force some special way of representing a blank line, eg.
> "", but then code wh
On Wed, 27 Aug 2025 at 15:16, Koichi Murase wrote:
>
> However, this isn't true. With these features implemented as shell
> options, in general, one actually needs to write it in the following
> way:
>
> local saved=$(shopt -p cmdsubst_trailing_nls) # (assume we are in a
> function)
> shopt -
possible. That is, if bash doesn't
have a trailing newline preserving command substitution, it is not possible to
write a preserve_trailing_nls function that makes $(foo |
preserve_trailing_nls) work as intended.
> Even if a consensus that "the frameworks don't need to handle
>
On Wed, 27 Aug 2025 at 18:41, Oğuz wrote:
> Hmm. How much control do you have on the input format? If it's not too late,
> rather than swimming against the current maybe you should alter the input so
> it can be easily parsed by a POSIX shell
I have a lot of control, but I'm not sure what this w
2025年8月27日(水) 17:30 Kevin Pulo :
> It's correct that using the shopt to change the behavior will, in general,
> break existing code that assumes the original unmodified behavior, and this is
> one of the main downsides of using shopts to modify behavior.
>
> However, I don't agree that the responsi
On Wednesday, August 27, 2025, Kevin Pulo wrote:
> I would still have to tell people
> "don't use $(), always do some_command > $tmpfile", which isn't much better
> than what I'm trying to avoid ("don't use $(), always use shopt -o
> lastpipe and
> do some_command | grab_output varname"). It's a
On Wed, 27 Aug 2025 at 15:16, Koichi Murase wrote:
> 2025年8月27日(水) 12:27 Kevin Pulo :
> > [...] (1) the choice of using shopts to modify behavior (vs
> > alternative syntax ala [3]; each of these approaches has pros and cons)
>
> I'm opposed to adding new shell options to change the behaviors of
On Wed, 27 Aug 2025 at 14:56, Oğuz wrote:
> I'm not against the proposed changes here but if this were me I'd store the
> command output in a temporary file and inspect that instead.
Unfortunately I don't think this helps all that much.
It introduces hoop-jumping to use/manage the temporary fil
Hello Oğuz!
Am Wed, 27 Aug 2025 07:59:53 +0300 schrieb Oğuz :
> On Wednesday, August 27, 2025, Martin Schulte
> wrote:
> >
> > foo=$(some_command ...).
> >
>
> The idea is retaining the trailing newlines in the output of `some_command'
> by leaving them behind another character while preserving
2025年8月27日(水) 12:27 Kevin Pulo :
> [...] (1) the choice of using shopts to modify behavior (vs
> alternative syntax ala [3]; each of these approaches has pros and cons), and
I'm opposed to adding new shell options to change the behaviors of
existing codes. If these options were added, we would nee
On Wednesday, August 27, 2025, Martin Schulte
wrote:
>
> foo=$(some_command ...).
>
The idea is retaining the trailing newlines in the output of `some_command'
by leaving them behind another character while preserving its exit code.
This loses the newlines
--
Oğuz
On Wednesday, August 27, 2025, Kevin Pulo wrote:
>
> I now have a use case which involves various combinations of command
> pipelines,
> with output sometimes stored in shell variables for inspection, before
> being
> finally output or fed into later pipelines. Bash is well suited for this,
> but
Hello Kevin!
Am Wed, 27 Aug 2025 13:26:08 +1000 schrieb Kevin Pulo :
> There are at least 3 common workarounds:
>
> foo=$(some_command ... ; rc=$? ; echo . ; exit $rc)
> rc=$?
> foo=${foo%.}
This can be written somewhat easier as
foo=$(some_command ...).
rc=$?
foo=${foo%.}
Best re
The issue where command substitution strips all trailing newlines comes up
regularly (eg. on this list [1] and stackoverflow [2]). This behavior is
historical and mandated by POSIX, and ensures that doing something like:
now=$(date)
echo "$now"
or:
now=$(date)
cat &
URL:
<https://savannah.gnu.org/bugs/?67326>
Summary: Bash 5.3: Problem with new in-process command
substitution ${..} on macOS
Group: The GNU Bourne-Again SHell
Submitter: None
Submitted: Wed 16 Jul 2025 02:07:39
On 1/12/24 1:06 PM, Oğuz wrote:
Why would that be unexpected, since you're explicitly running something
in the calling shell's context, with the expected side effects to that
environment?
I wasn't clear. This doesn't exit the shell
bash-5.3$ exec foo
bash: exec: foo: not found
On Fri, Jan 12, 2024 at 7:05 PM Chet Ramey wrote:
> Nofork command substitution freezes the jobs list, because you don't
> want jobs appearing and disappearing in the list while you're running
> word expansion. If the jobs list is frozen, wait -n doesn't even try
> wa
On 1/4/24 8:36 AM, Oğuz wrote:
These bugs affect the development branch only.
1. `wait -n' doesn't work inside nofork command substitution. I think
it should, or wait without `-n' shouldn't work either, or what works
and what doesn't should be documented.
Nofork com
On 1/3/24 4:36 PM, Martin Schulte wrote:
I couldn't reproduce this with neither 5.1.4 nor 5.2.15 - in both cases
${ case } in }) echo uname; esac }
results in
bash: syntax error near unexpected token `)'
https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html
--
``The lyf so shor
These bugs affect the development branch only.
1. `wait -n' doesn't work inside nofork command substitution. I think
it should, or wait without `-n' shouldn't work either, or what works
and what doesn't should be documented.
$ sleep 3 & sleep 1; echo ${| w
On Wed, 3 Jan 2024 22:36:34 +0100
Martin Schulte wrote:
> Hello Oğuz!
>
> > See:
> >
> > $ ${ case } in }) echo uname; esac }
> > Linux
> > $ ${ case }x in }x) echo uname; esac }
> > bash: command substitution: line 25: syntax error n
Hello Oğuz!
> See:
>
> $ ${ case } in }) echo uname; esac }
> Linux
> $ ${ case }x in }x) echo uname; esac }
> bash: command substitution: line 25: syntax error near unexpected token
> `x'
> bash: command substitution: line 25: `}x)'
>
On 1/3/24 8:41 AM, Oğuz wrote:
See:
$ ${ case } in }) echo uname; esac }
Linux
$ ${ case }x in }x) echo uname; esac }
bash: command substitution: line 25: syntax error near unexpected token `x'
bash: command substitution: line 25: `}x)'
$ ${ case
See:
$ ${ case } in }) echo uname; esac }
Linux
$ ${ case }x in }x) echo uname; esac }
bash: command substitution: line 25: syntax error near unexpected token `x'
bash: command substitution: line 25: `}x)'
$ ${ case }x in \}x) echo uname; esac }
Linu
gives a syntax error when using the $(...) form of
> command substitution and timing grouped commands.
>
> However, Bash works correctly when using the `...` form of
> command substitution.
>
>
> Repeat-By:
>
> The 'time' built-in command can m
) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Bash gives a syntax error when using the $(...) form of
command substitution and timing grouped commands.
However, Bash works correctly when using
Hi,
With the new funsub syntax ${ cmd;} and ${| cmd;} that encourages
returning the value of $REPLY to the caller, I've been thinking about
an idiomatic way of doing error handling and propagation that may
call for a new shell option or new type of funsub.
So the idea is natural, when a function
On Wed, 21 Jun 2023 09:01:20 -0400
Greg Wooledge wrote:
> On Wed, Jun 21, 2023 at 09:54:30AM +0100, Kerin Millar wrote:
> > On Wed, 21 Jun 2023 14:11:28 +0530
> > LitHack wrote:
> >
> > > But why this not worked in zsh.
> >
> > I don't use zsh. A fairly plausible explanation would be that its
On Wed, Jun 21, 2023 at 09:54:30AM +0100, Kerin Millar wrote:
> On Wed, 21 Jun 2023 14:11:28 +0530
> LitHack wrote:
>
> > But why this not worked in zsh.
>
> I don't use zsh. A fairly plausible explanation would be that its alias
> builtin ignores the request to declare an alias, if issued in a
On Wed, 21 Jun 2023 14:11:28 +0530
LitHack wrote:
> But why this not worked in zsh.
I don't use zsh. A fairly plausible explanation would be that its alias builtin
ignores the request to declare an alias, if issued in a subshell.
--
Kerin Millar
On Wed, 21 Jun 2023 13:40:56 +0530
LitHack wrote:
> Normally declaring a alias inside the command substitution would not
> reflect in main shell like
> lithack@aura:~$ `alias l=ls`
> lithack@aura:~$ l
> l: command not found
> But using this command .
> lithac
Normally declaring a alias inside the command substitution would not
reflect in main shell like
lithack@aura:~$ `alias l=ls`
lithack@aura:~$ l
l: command not found
But using this command .
lithack@aura:~$ `alias l=ls;alias`
lithack@aura:~$ l
api Desktop Downloads Music
These are both very useful!
On 5/25/23 1:19 PM, Robert Elz wrote:
Date:Thu, 25 May 2023 10:17:01 -0400
From:Chet Ramey
Message-ID:
| a nofork command substitution is
| '${' compound_list '}',
you omitted the extra char there, not that it matters for
the purpo
Date:Thu, 25 May 2023 10:17:01 -0400
From:Chet Ramey
Message-ID:
| a nofork command substitution is
| '${' compound_list '}',
you omitted the extra char there, not that it matters for
the purpose here.
| The difference, as you say, i
On 5/25/23 8:13 AM, Robert Elz wrote:
Note that ${C } is not a group - it is syntax that delimits a command
substituition in a word, and what's in a command substitution is a list
(which can contain groups, or be one, but isn't required to be).
There's not any real difference.
On 5/25/23 6:29 AM, Koichi Murase wrote:
2023年5月24日(水) 22:27 Chet Ramey :
[...]
Thanks for testing it.
Thank you for all the explanations and clarifications.
Both are valid, but don't get too fond of ${(command)} -- I'm going to
remove it in favor of people using ${ (command); } if they wa
grammar similar to the existing one for the Principle Of Least
Astonishment or like that. I admit that what would be the POLA design
could depend on the person, so we can discuss it.
> What Chet is planning on removing is allowing the 'C' in the opening ${C
> that indicates that this i
word position.
Any other syntax that allows that to happen should be OK.
What Chet is planning on removing is allowing the 'C' in the opening ${C
that indicates that this is a command substitution, and not some other kind
of expansion, will no longer have the case where C==
2023年5月24日(水) 22:27 Chet Ramey :
> > [...]
>
> Thanks for testing it.
Thank you for all the explanations and clarifications.
> Both are valid, but don't get too fond of ${(command)} -- I'm going to
> remove it in favor of people using ${ (command); } if they want a subshell.
Does that mean ${(co
On 5/23/23 2:50 PM, Grisha Levit wrote:
One more similar case when the parameter expansion is quoted:
bash --norc -in <<<$'"${_+$("\n")}"'
bash-5.2$ "${_+$("
bash: command substitution: line 2: unexpected EOF while looking for
matching `&quo
On 5/23/23 4:17 PM, Grisha Levit wrote:
An interactive shell gets confused (PS1 shown instead of PS2) when using
newline as the first character of the substitution:
$ bash --norc -i <<<$'${\n:;}'
bash-5.2$ ${
bash-5.2$ :;}
Thanks for the report.
Chet
--
``The lyf so short, the craft so long
On 5/23/23 4:17 PM, Grisha Levit wrote:
Things don't seem to work right with an empty funsub:
bash --pretty-print <<<'${ }'
${ ; }
It should allow the empty command substitution, like $(), and not add the
`;' when it reconstitutes the text.
--
``The lyf so shor
On 5/23/23 6:52 AM, Koichi Murase wrote:
I really appreciate that the feature ${ command; } is finally
implemented. I have a function that mimics the behavior of the nofork
command substitution in my project. I changed the function to switch
to use the new nofork command substitutions in new
An interactive shell gets confused (PS1 shown instead of PS2) when using
newline as the first character of the substitution:
$ bash --norc -i <<<$'${\n:;}'
bash-5.2$ ${
bash-5.2$ :;}
Things don't seem to work right with an empty funsub:
bash --pretty-print <<<'${ }'
${ ; }
$ bash -c '${ }'
On Mon, Mar 20, 2023 at 4:59 PM Chet Ramey wrote:
> Thanks for the report. This is the same thing as
>
> https://lists.gnu.org/archive/html/bug-bash/2021-06/msg00115.html
>
> with the command substitution being embedded in the parameter expansion.
One more similar case whe
2023年5月16日(火) 2:35 Chet Ramey :
> The latest devel branch push has the initial implementation of `nofork'
> command substitution. The excerpt from the info manual describing it is
> appended.
>
> Please test it out, and find the places I missed. Thanks.
I really appreci
Op 22-05-2023 om 16:18 schreef Chet Ramey:
I'd call that a bug. It's not how mksh documents this type of command
substitution to work. ksh93 documents the parsing the same way.
So it does, yet ksh93 also accepts omitting the ;.
The only documentation of this is in the legacy chang
n such cases, the value to be assigned needs to come from somewhere,
and I can't really see a lot of benefit in using this indirect method
of getting that value, rather that simply putting the somewhere directly
in the word, instead of this command substitution, except in the most
unlikely of
This will be a very neat feature to have. One thing I'm excited about
is the ability to cleanly perform assignments during prompt expansion
(e.g. to capture information during PS0 or PS4 expansion).
Something I suspect people will complain about is that this change
makes some polyglot zsh/bash sc
On 5/19/23 12:39 PM, alex xmb ratchev wrote:
after ${| set -- 1 2 3 } , 1 2 3 are no more .. right ?
;} or space} to end .. ?
The portion of the documentation I posted says:
"the close brace must be in a position where a reserved word may appear
(i.e., preceded by a command terminator s
On 5/19/23 11:56 AM, alex xmb ratchev wrote:
Command substitution is a word expansion; word expansions are performed on
words; command substitution occurs as part of a word. That all seems
self-evident. The only reason to mention it is the quirk required to have
the close brace
On 5/19/23 7:36 AM, alex xmb ratchev wrote:
'C ..'
' ..'
'| ..'
.. i dont get it
The `C' is the result of how info renders @var, used to indicate meta-
syntactic variables (COMMAND is another).
In other formats, it would be more apparent that it's not a literal `C'
and that it's like the `COM
On Fri, May 19, 2023, 22:08 Chet Ramey wrote:
> I don't think this ever made it to the list.
>
>
> -- Forwarded message --
> From: Chet Ramey
> To: "Ángel"
> Cc: chet.ra...@case.edu
> Bcc:
> Date: Wed, 17 May 2023 11:53:46 -0400
> Su
I don't think this ever made it to the list.--- Begin Message ---
On 5/16/23 5:40 PM, Ángel wrote:
On 2023-05-15 at 13:35 -0400, Chet Ramey wrote:
There is an alternate form of command substitution:
${C COMMAND; }
I find this description confusing, as it looks like a liter
On Fri, May 19, 2023, 21:11 Greg Wooledge wrote:
> On Fri, May 19, 2023 at 06:35:50PM +0200, alex xmb ratchev wrote:
> > so that i understand ,
> >
> > var=${ awk ... }
>
> There's no reason to use this new thing if you're calling awk, because
> awk is an external program. You might as well just
On Fri, May 19, 2023 at 06:35:50PM +0200, alex xmb ratchev wrote:
> so that i understand ,
>
> var=${ awk ... }
There's no reason to use this new thing if you're calling awk, because
awk is an external program. You might as well just use var=$( awk ... )
instead.
Either way, you're going to for
mple
> | assignment to REPLY.
>
> In such cases, the value to be assigned needs to come from somewhere,
> and I can't really see a lot of benefit in using this indirect method
> of getting that value, rather that simply putting the somewhere directly
> in the word, instead o
tting the somewhere directly
> in the word, instead of this command substitution, except in the most
> unlikely of cases (like when REPLY is built up gradually, via a loop
> gradually adding more text).
>
> | I envision a little more complexity than that; a ${| printf -v REPLY
o come from somewhere,
and I can't really see a lot of benefit in using this indirect method
of getting that value, rather that simply putting the somewhere directly
in the word, instead of this command substitution, except in the most
unlikely of cases (like when REPLY is built up gradually,
xpansions, command substitutions, arithmetic
>> > expansion, tilde exbansion, and in bash and some other shells, brace
>> > expansion) are all word expansions. All of them occur anywhere in a
>> > shell "word", and I don't see this proposed new form as bein
no
> names:
> >| ${| read; }
> >
> > I'd have thought a more likely example would be
> >
> > ${| printf -v REPLY 'whatever format' arg... ;
>
> Maybe, and certainly possible, but a more likely use is just a simple
> assignment t
ion, and in bash and some other shells, brace
expansion) are all word expansions. All of them occur anywhere in a
shell "word", and I don't see this proposed new form as being any different.
It's not. It's command substitution.
The only oddity is that inside the nofork cmd s
t; >> as a reserved word would usually require.
> >
> > I had to read this a couple of times to figure out what it means. In
> > particular "the word" isn't well-bound here.
>
> Command substitution is a word expansion; word expansions are performed on
&g
On Fri, May 19, 2023, 14:55 Greg Wooledge wrote:
> On Fri, May 19, 2023 at 02:25:15PM +0200, alex xmb ratchev wrote:
> > On Fri, May 19, 2023, 13:54 Greg Wooledge wrote:
> >
> > > On Fri, May 19, 2023 at 01:36:44PM +0200, alex xmb ratchev wrote:
> > > > 'C ..'
> > > > ' ..'
> > > > '| ..'
> > >
means. In
particular "the word" isn't well-bound here.
Command substitution is a word expansion; word expansions are performed on
words; command substitution occurs as part of a word. That all seems
self-evident. The only reason to mention it is the quirk required to have
the clo
On 5/18/23 9:58 PM, Dale R. Worley wrote:
Ángel writes:
I suggest:
There is an alternate form of command substitution:
${ COMMAND; }
and clarify later the other variants in addition to a space:
The character following the open brace must be a space, tab,
newline, '(
On Fri, May 19, 2023 at 02:25:15PM +0200, alex xmb ratchev wrote:
> On Fri, May 19, 2023, 13:54 Greg Wooledge wrote:
>
> > On Fri, May 19, 2023 at 01:36:44PM +0200, alex xmb ratchev wrote:
> > > 'C ..'
> > > ' ..'
> > > '| ..'
> > >
> > > .. i dont get it
> >
> > Yeah, the wording isn't ideal. I
On Fri, May 19, 2023, 14:25 alex xmb ratchev wrote:
>
>
> On Fri, May 19, 2023, 13:54 Greg Wooledge wrote:
>
>> On Fri, May 19, 2023 at 01:36:44PM +0200, alex xmb ratchev wrote:
>> > 'C ..'
>> > ' ..'
>> > '| ..'
>> >
>> > .. i dont get it
>>
>> Yeah, the wording isn't ideal. I'd start it out l
On Fri, May 19, 2023, 13:54 Greg Wooledge wrote:
> On Fri, May 19, 2023 at 01:36:44PM +0200, alex xmb ratchev wrote:
> > 'C ..'
> > ' ..'
> > '| ..'
> >
> > .. i dont get it
>
> Yeah, the wording isn't ideal. I'd start it out like this:
>
yea better ..
${ COMMAND; }
> ${| COMMAND; }
>
On Fri, May 19, 2023 at 01:36:44PM +0200, alex xmb ratchev wrote:
> 'C ..'
> ' ..'
> '| ..'
>
> .. i dont get it
Yeah, the wording isn't ideal. I'd start it out like this:
${ COMMAND; }
${| COMMAND; }
Execute COMMAND in the current execution environment
The first form (where the c
'C ..'
' ..'
'| ..'
.. i dont get it
On Mon, May 15, 2023, 19:35 Chet Ramey wrote:
> The latest devel branch push has the initial implementation of `nofork'
> command substitution. The excerpt from the info manual describing it is
> appended.
&
less frills) and select, and so is a var
name already more or less reserved for the shell's internal use (like OPTIND,
OPTARG, IFS, ...) and was just used for the purpose. Personally I'd
prefer if this kind of command substitution
[On trailing \n]
| Is that what you intend the code
he word" isn't well-bound here. Perhaps better is
> The characters immediately following the close brace continue the word
> that the command substitution is part of; the close brace need not be
> followed by a shell metacharacter as a reserved word would usually
> require.
T
Ãngel writes:
> I suggest:
>
>> There is an alternate form of command substitution:
>>
>> ${ COMMAND; }
>
> and clarify later the other variants in addition to a space:
>
>> The character following the open brace must be a space, tab,
>> n
On 2023-05-15 at 13:35 -0400, Chet Ramey wrote:
> There is an alternate form of command substitution:
>
> ${C COMMAND; }
I find this description confusing, as it looks like a literal 'C'.
I suggest:
> There is an alternate form of command substitution:
On 5/15/23 2:54 PM, Oğuz İsmail Uysal wrote:
On 5/15/23 9:51 PM, Chet Ramey wrote:
Everything is shared between the comsub and its caller, with a
couple of documented exceptions. So it's just like calling `fg' in the
current execution environment, but capturing the output.
Oh, okay then. Thanks
On 5/15/23 9:51 PM, Chet Ramey wrote:
Everything is shared between the comsub and its caller, with a
couple of documented exceptions. So it's just like calling `fg' in the
current execution environment, but capturing the output.
Oh, okay then. Thanks.
How about this?
$ declare -i x
$ y
On 5/15/23 2:42 PM, Oğuz İsmail Uysal wrote:
On 5/15/23 8:35 PM, Chet Ramey wrote:
Please test it out
$ cat
^Z
[1]+ Stopped cat
$ x=${ fg;}
foo
foo
<^C or ^D here>
$ declare -p x
declare -- x="cat"
$
Is this intended?
So far
1 - 100 of 552 matches
Mail list logo
