On Mon, Jul 8, 2024, 22:57 Greg Wooledge wrote:
> On Mon, Jul 08, 2024 at 22:45:35 +0200, alex xmb sw ratchev wrote:
> > On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote:
> >
> > > On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
> > >
> > > > hi , one question about ..
> > > > if a cmd contains more su
On Mon, Jul 08, 2024 at 22:45:35 +0200, alex xmb sw ratchev wrote:
> On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote:
>
> > On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
> >
> > > hi , one question about ..
> > > if a cmd contains more substitions like >( or <( , how to get all $!
> > > maybe make ${
On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote:
> On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
>
> > hi , one question about ..
> > if a cmd contains more substitions like >( or <( , how to get all $!
> > maybe make ${![]} , or is such already .. ?
>
> You can't. Process substitutions set $!, but y
On 7/8/24 4:02 PM, alex xmb sw ratchev wrote:
hi , one question about ..
if a cmd contains more substitions like >( or <( , how to get all $!
maybe make ${![]} , or is such already .. ?
You can't. Process substitutions set $!, but you have to have a point
where you can capture that if you want
On Mon, Jul 8, 2024, 21:55 Chet Ramey wrote:
> On 7/8/24 3:27 PM, Dale R. Worley wrote:
> > Greg Wooledge writes:
> >> Some scripts use something like this:
> >> ...
> >> exec > >(command ...) ...
> >
> > I've used that construction quite a few times myself. I'm not
> > requesting that the
On 7/8/24 3:27 PM, Dale R. Worley wrote:
Greg Wooledge writes:
Some scripts use something like this:
...
exec > >(command ...) ...
I've used that construction quite a few times myself. I'm not
requesting that the resulting process be waitable, but certainly
whatever the maintainers desi
Greg Wooledge writes:
> Some scripts use something like this:
> ...
> exec > >(command ...) ...
I've used that construction quite a few times myself. I'm not
requesting that the resulting process be waitable, but certainly
whatever the maintainers design should take into account that this is
On 7/5/24 4:38 PM, Emanuele Torre wrote:
More funny things have been discovered since.
It has been brought up when discussing this in the #bash IRC channel of
irc.libera.chat, that if you run eval '
This is a consequence of using the same code for a number of things: the
same function handle
Emanuele Torre writes:
> Yes, clearly that is influencing this new behaviour, but this is new:
> <((
On 7/5/24 2:38 PM, Emanuele Torre wrote:
Bash 5.2 apparently added <(< file) that expand to the path to a fifo
(openable only for read on BSD) to which the contents of file are
written to, without documenting it.
It's a side effect of making the internal implementations of command and
process
On Mon, Jul 8, 2024 at 11:16 AM Martin D Kealey wrote:
> The only things that the shell has going for it is that it's widely deployed
> and stable over the long term.
> Otherwise it's a terrible language, and any sane programmer should avoid it
> entirely:
> This has already been happening, and
@Greg, @Martin +1, lost sight of the feature, and xing fingers that current
semantic/behavior is not destroyed, @Oğuz -1 I'd like to avoid fixing
script that run today just because bash was updated or I would advocate
distros to keep a frozen bash as macos did.
On Mon, Jul 8, 2024, 10:16 Martin D Kealey wrote:
>
>
> On Mon, 8 Jul 2024 at 14:42, Oğuz wrote:
>
>> On Monday, July 8, 2024, Martin D Kealey wrote:
>>>
>>> It's not possible to change "${BASH_SOURCE[@]}" without breaking some
>>> existing code,
>>>
>>
>> It's worth breaking existing code in t
On Mon, 8 Jul 2024 at 14:42, Oğuz wrote:
> On Monday, July 8, 2024, Martin D Kealey wrote:
>>
>> It's not possible to change "${BASH_SOURCE[@]}" without breaking some
>> existing code,
>>
>
> It's worth breaking existing code in this case.
>
The only things that the shell has going for it is th
14 matches
Mail list logo
