Yes, thanks, that part I figured out many lines of code ago ;-)
Chet answer earlier today kind of closed the loop on my "observations". By
design, as soon as you work with FD by varname you have to do all the
housekeeping (regardless on how you create them). But, depending on how
you use regular
On 1/28/16 6:56 PM, Reuti wrote:
> The man page of bash 4.2 says about REDIRECTION: In this case [...] the shell
> will allocate a file descriptor greater than 10 and assign it to varname.
>
> While looking into this discussion, I get 10 as first varname assigned in
> this way. Either a bug in
Hi,
Am 28.01.2016 um 23:25 schrieb Andreas Schwab:
> Mathieu Patenaude writes:
>
>> The issue I see with relying on the bash EXIT to actually have the system
>> do the cleanup is when you have a script that does things in a forever
>> loop, you end up with FD exhaustion when using "named" FD an
In 'help typeset', the 'typeset' builtin is called obsolete and has been
so since at least bash 2.05b (2002) or possibly earlier. Perhaps it's
time to just call it a synonym, as indeed the texinfo documentation does.
diff -ur bash-4.4-beta.orig/builtins/declare.def
bash-4.4-beta/builtins/declare.d
Mathieu Patenaude writes:
> The issue I see with relying on the bash EXIT to actually have the system
> do the cleanup is when you have a script that does things in a forever
> loop, you end up with FD exhaustion when using "named" FD and here strings.
Of course, if you don't close (or reuse) yo
Chet, thanks for the clarification
So the answer is - this is by design, i.e. as soon as you use a variable
for the FD, you are responsible of managing it for the duration of its life.
Knowing this makes it much more "reliable" to use ;-) I also could not
find the relevant info on the list / web
I guess the question remains, why does a "here string" assigned to a named
FD rely on the system to the the clean-up but when assigned to a regular,
numbered FD, it does not?
The issue I see with relying on the bash EXIT to actually have the system
do the cleanup is when you have a script that doe
On 1/27/16 1:18 PM, Mathieu Patenaude wrote:
> Hi,
>
> When using "named" file descriptors inside a function, the file descriptors
> are not automatically un-linked when the function returns, but when using
> regular "numbered" file descriptors they are automatically "destroyed".
Yes. That's the
On Thu, Jan 28, 2016 at 12:40:57PM -0500, Mathieu Patenaude wrote:
> Yes, using ":" also illustrate the same (or similar) behavior that I'm
> experiencing with my script. Using the "here" string creates the
> additional weirdness of showing that the temporary file content is actually
> "deleted",
Yes, using ":" also illustrate the same (or similar) behavior that I'm
experiencing with my script. Using the "here" string creates the
additional weirdness of showing that the temporary file content is actually
"deleted", but the bash process keep the FD open. Which is quite strange
since it app
Greg Wooledge writes:
> On Wed, Jan 27, 2016 at 01:18:11PM -0500, Mathieu Patenaude wrote:
>> When using "named" file descriptors inside a function, the file descriptors
>> are not automatically un-linked when the function returns, but when using
>> regular "numbered" file descriptors they are au
On Wed, Jan 27, 2016 at 01:18:11PM -0500, Mathieu Patenaude wrote:
> When using "named" file descriptors inside a function, the file descriptors
> are not automatically un-linked when the function returns, but when using
> regular "numbered" file descriptors they are automatically "destroyed".
Cou
12 matches
Mail list logo
