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

[Chet Ramey]

On 11/17/24 1:16 PM, Mike Peters wrote:
> On 2024-11-16 22:56, Lawrence Velázquez wrote:
> > 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.
>
> I don't know what documentation it was missing from, but this usage is 
> consistent and logically valid with the manual...

It is not. The special case of $(< file) being equivalent to $(cat file)
is documented. Nothing else is.

> 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'.

So you have defined a process substitution with a simple command
consisting of a single redirection.

 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.

`< file' is a valid simple command. It just doesn't do what you think it
does. Its behavior is described here:

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_09_01_03

It's roughly equivalent to `( : < file )', which opens the file and closes
it, erroring if the file can't be opened for reading. The fact that `:' is
a POSIX special builtin doesn't really matter here. It certainly doesn't
spit the file contents to the standard output.


 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).

It does, in the sense that it's a valid command that won't result in a
syntax error. It just doesn't do what you want going forward, and it's
unlikely to.

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

Why would I document removing an undocumented, undesired implementation
artifact in the manual? It will be in the list of changes in the next
release, like other bug fixes.

> * (Although I have yet to determine any purpose or significance of these 
> redirections in the manual, other than simply not causing an error, as it 
> "do[es] not affect the current shell environment", and there is "no command 
> name", so what is there remaining to affect?)

You can perform side effects, which are sometimes desirable. For example,
creating a file using `> file' instead of `touch file'.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature