On Tue, Apr 21, 2020 at 08:38:41PM -0400, Dale R. Worley wrote:
> The "unbuffered pipe" symbol ">|>" causes Bash to set in the
> environment of the "grep" process a variable "STDOUT_UNBUFFERED" with
> a value that contains the dev and ino values for the pipe which the
> "grep" process sees as fd 1.
I've written a feature I find useful for bash that escapes a single ampersand
if it is surrounded on both sides by any non-blank or non-meta characters. This
logic is toggled by a set option, "compressedand" that can be enabled with `set
[-|+]c` or `set -o compressedand`.
As an example:
$
Hello,
Is the following an intended behavior? Undefined? A bug?
$ a[1]=2; declare -n ref=a[1]; echo $ref $((ref))
2 0
Thanks,
Daniel
Greg Wooledge writes:
> On Tue, Apr 21, 2020 at 08:38:41PM -0400, Dale R. Worley wrote:
>> The "unbuffered pipe" symbol ">|>" causes Bash to set in the
>> environment of the "grep" process a variable "STDOUT_UNBUFFERED" with
>> a value that contains the dev and ino values for the pipe which the
>>
The crux of the problem, IMHO, is to look at it from the right angle:
Occasionally, the user desires that I/O through certain pipes should be
unbuffered, that is, the stdio stream(s) that write into the pipe should
be unbuffered, rather than the default block-buffered. These are
situations where
