On 24.7. 21:43, L A Walsh wrote:
Does it improve execution time? That's more of a concern here than
readability, since it is an expression fragment, it isn't meant to be
understood
in isolation.
[...]
The important part for me is whether or not it is faster to perform
1 calculation,
On Thu, Jul 25, 2019 at 10:29:08AM -0700, L A Walsh wrote:
> On 2019/07/24 11:49, Greg Wooledge wrote:
> > $((expression))
> >
> >The expression is treated as if it were within double quotes,
> I didn't use $((...)), I'd put the whole thing in ((...)) which I hoped
> would
On 2019/07/24 11:49, Greg Wooledge wrote:
> On Wed, Jul 24, 2019 at 11:43:11AM -0700, L A Walsh wrote:
>
>> Those aren't my variables.
>> If you assign the integer attribute to a variable it isn't the same
>> as when you don't.
>>
>
> In this case it *is*, because everything is being fed
On 7/25/19 9:03 AM, Sam Liddicott wrote:
> Perhaps if the named fd is also closed on the same statement that opened
> it, it could be kept closed rather than saved and re-opened.
> Being closed at the same statement is a strong indicator that it was only
> used to aid fd transplants. Why keep open
Thanks for your continued engagement, it is appreciated.
I was focused on my case where I used _ as the name of the file descriptor
because I didn't want to retain it, for I was using named fd as a way to
avoid trampling on an fd already in use, rather than as an open method.
I'm writing up a she
On 7/23/19 9:16 PM, Anthony Thyssen wrote:
> OS: Fedora 28, Running on a Dell Latitude E7450
> Standard RPM Package: bash-4.4.23-1.fc28.x86_64
>
>
> if you type a multi-line if-then-else-fi statement with a command before the
> else.
> Bash does not add a semi-colon before the else when savi
On 7/24/19 9:07 AM, Sam Liddicott wrote:
> Thanks for that thoughtful response.
>
> * I understand that the design decision is to have variable file
> descriptors to stay open after per-command redirection
Yes.
> * I understand that implementation constraints make it impossible to do
> this unif
