On Wed, 23 Aug 2023, 12:20 Greg Wooledge, wrote:
> > echo Hi {X}>/dev/null
> > ls -l "/proc/$$/fd/$X"
>
> That's a really strange example. I wonder what would lead someone to
> write that particular redirection.
Oh I merely wanted to point out that the redirection persists beyond the
echo comm
On Wed, Aug 23, 2023 at 12:05:42PM +1000, Martin D Kealey wrote:
> On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote:
>
> > Excuse me now, while I go and close several open FDs in the shell where
> > I tested something the other day, which I had no idea were left open.
> >
>
> It's even worse than
On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote:
> Excuse me now, while I go and close several open FDs in the shell where
> I tested something the other day, which I had no idea were left open.
>
It's even worse than that; try:
echo Hi {X}>/dev/null
ls -l "/proc/$$/fd/$X"
-Martin
>
On Tue, Aug 22, 2023 at 02:59:14PM -0400, Dale R. Worley wrote:
> The "{var}>..." mechanism *assigns* to $var, rather than
> taking its existing value.
... oh. Well, today I learned something.
Excuse me now, while I go and close several open FDs in the shell where
I tested something the other da
On 8/22/23 2:59 PM, Dale R. Worley wrote:
Is there any way to write a redirection "Redirect the fd whose number is
in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and
assemble a command string however you want. But is there a direct way
to write it? The "{var}>..." mechanism *assi
Is there any way to write a redirection "Redirect the fd whose number is
in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and
assemble a command string however you want. But is there a direct way
to write it? The "{var}>..." mechanism *assigns* to $var, rather than
taking its existin
On 8/21/23 5:50 PM, Grisha Levit wrote:
The new read -E option is a nice addition.
I think it's not unreasonable for a completion function to itself invoke
`read' (with a file or pipe as input, not a tty) and this mostly works out
fine, unless the -d option is used since the builtin stores the de
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
