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: Sun, 17 Nov 2024 14:48:03 -0500

On Sun, Nov 17, 2024, at 1:16 PM, Mike Peters wrote:
> On 2024-11-16 22:56, Lawrence Velázquez wrote:
>> Be aware that <(<file) is undocumented and was removed [1] after
>> Emanuele brought it up [2]; it will not work in future releases.
>
> I don't know what documentation it was missing from, but this usage is 
> consistent and logically valid with the manual... Process substitution 
> 'takes the form of <(list) or >(list)'. The grammar defines 'list' to 
> be 'a sequence of one or more pipes', a 'pipeline' to be 'a sequence of 
> one or more commands'. Command substitution takes the form $(command) 
> or `command`, and since `<file` is valid as specified by the cat 
> shortcut, <file must be a valid simple command. SIMPLE COMMAND 
> EXPANSION explicit allows redirections*: "If no command name results, 
> redirections are performed, but do not affect the current shell 
> environment." Thus the manual's grammar technically does document the 
> validity of <(<file).

I wasn't clear.  <(<file) remains valid syntactically, but it no
longer behaves like <(cat file).


> I hope it's removal is documented in the manual.

The removed behavior was not documented to begin with.


>> 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.
>>
>
> I disagree. The REDIRECTION section of the manual uses the word 'word' 
> when it might refer to either a file descriptor or a file, so I think 
> "there might be an argument" if the declaration involved incorporating 
> 'word' in place of 'file'.

That wouldn't really make a difference.  The important changes would
be adding a redirection to the first substitution and removing the
space from the second.  A simple "file"/"word" swap wouldn't justify
the confusion...

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

...since $(cat &3) and $(< &3) are still nonsense.

(Also, in the manual "&n" is never a valid substitution for "word".)


-- 
vq



reply via email to

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