Re: Unbuffered pipes: cases to be supported
On 2020-04-23 at 20:20 -0400, Dale R. Worley wrote: > The cases I've found where bash allocates a pipe, and thus an unbuffered > pipe may be wanted, are: What are you trying to solve? How do you expect those "Unbuffered pipes" to be implemented? I don't think there is any buffering going on in the pipes itself. The problem is likely to be at the program *writing* to the pipe. Which is out of the scope of bash itself. You may want to run them through stdbuf Best regards
Re: Variable references (declare -n, "nameref") are limited to a depth of 8.
On 4/25/20 2:55 AM, andrej--- via Bug reports for the GNU Bourne Again SHell wrote: > Bash Version: 5.0 > Patch Level: 16 > Release Status: release > > Description: > > While looking for a way to share a "cache" array with a recursive function > call stack (using local -n (nameref)), I hit a well-known problem with > "circular name reference" (which has been around for a long time). Yes, that's how it does loop detection. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Variable references (declare -n, "nameref") are limited to a depth of 8.
>> Description: >> >> While looking for a way to share a "cache" array with a recursive function >> call stack (using local -n (nameref)), I hit a well-known problem with >> "circular name reference" (which has been around for a long time). > > Yes, that's how it does loop detection. There are, however, no loops involved in my $a … $k example; it is merely a chain of declare -n references starting from a regular variable $a. The chain breaks unexpectedly and silently after 8 links ($j and $k appear to be empty). Better options, IMHO, would include: (a) An unlimited number of declare -n resolution steps (as long as there are no cycles, i.e., no variable name(*) is encountered twice). This may have performance consequences when abused, but it would be better than unexpected empty values after >8 steps. (b) An error message when trying to dereference $j or $k (links No. 9 and 10 in the chain example), saying e.g. “maximum nameref depth (8) exceeded”. This would at least make the problem obvious and easy to debug. (*) More precisely, this would be [function context, variable name] pairs in case of local variables referenced by declare -n. Andrej
