bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: redirection / process substitution fails to read a file descriptor


From: Lawrence Velázquez
Subject: Re: redirection / process substitution fails to read a file descriptor
Date: Sat, 16 Nov 2024 23:56:59 -0500

On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote:
> On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
>> Description:
>>         Process substitution does not generate properly when pulling from 
>> another file descriptor, although it works when pulling from a file 
>> directly. In the below sample shell session, it is expected that 
>> `<(<test.txt)` would be functionally equivalent to `<(<&3)`.
>
>
>> Repeat-By:
>>         > echo foobar > test.txt
>>         > echo `< <(<test.txt)`
>>         foobar

Be aware that <(<file) is undocumented and was removed [1] after
Emanuele brought it up [2]; it will not work in future releases.
However, the "issue" does affect command substitutions:

        $ echo foobar >test.txt
        $ echo "$(<test.txt)"
        foobar
        $ exec 3<test.txt
        $ echo "$(<&3)"

        $

[1] 
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=d3e86e66ce857a8dc02e3116fd98b6e5b34d6364
[2] https://lists.gnu.org/archive/html/bug-bash/2024-07/msg00045.html


> I'm guessing that the parser sees the <& and decides *not* to treat
> this as a shortcut of cat with &3 as a filename.  Therefore, the only
> thing the parser can do is treat this as an empty command with a <&3
> redirection attached to it.

As I understand the code [3][4], <file ("r_input_direction") is a
candidate for the "cat" optimization, <&n ("r_duplicating_input")
isn't, and the decision is made after parsing, so there's no way
&n could be interpreted as a filename.

Note that the actual documentation for this feature doesn't say or
imply that <&n should work:

        The command substitution $(cat file) can be replaced by the
        equivalent but faster $(< file).

This reading doesn't make much sense:

        The command substitution $(cat &n) can be replaced by the
        equivalent but faster $(< &n).

There might be an argument for it if the documentation read:

        The command substitution $(cat <file) can be replaced by
        the equivalent but faster $(<file).

But it doesn't.

[3] 
https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/evalstring.c?h=devel&id=fa68e6da80970c302948674369d278164a33ed39#n198
[4] 
https://git.savannah.gnu.org/cgit/bash.git/tree/make_cmd.c?h=devel&id=fa68e6da80970c302948674369d278164a33ed39#n663

-- 
vq



reply via email to

[Prev in Thread] Current Thread [Next in Thread]