0

I'm trying to pass multiple outputs to a command using sub-processes. This is (a shortened version of) my command:

cat "$1"
one=cat "$1"

The output of command <(echo "foo") is

foo
/dev/fd/63: Permission denied

Since cat "$1" works I assume the function has the permission to read the output of the sub-process', but permission is denied when I attempt to put it into a variable. Why is this, and is there any way around it?

  • I assume your one=.. is meant to be something like one=$(...) – Stephen Harris Feb 23 at 2:04
  • 1
    one=cat "$1" will try to run $1 (/dev/fd/63) as an executable with the one=cat variable in its environment. That will fail with "Permission denied" because /dev/fd/63 is a pipe, not a binary or script executable. – Uncle Billy Feb 23 at 2:24
  • Because you tried to read from a pipe. ls -la <(:) should show you that. – Jetchisel Feb 23 at 3:56
0

Your question isn't totally clear. But I'm guessing you have a command called x that does something like:

cat "$1"
one=$(cat "$1")

Now when you do x <(echo "foo") you get an error.

Now this is because of how the <(...) structure works.

Basically it runs echo foo and connects the output of that to a temporary file handle (/dev/fd/63) and then passes that as a parameter.

So now your first cat command reads the whole of the input. Which means there's no input left. So your second cat command has nothing to read. And you get an error because the echo process has finished and there's no open handle to read.

In a simple form, you've done a special version of

echo "foo" | {
  cat
  one=$(cat)
}

but with clever file handling magic.

| improve this answer | |
  • "And you get an error because the echo process has finished and there's no open handle to read." I can't follow that. I would expect the second cat to get an EOF without error. How does that explain the /dev/fd/63: Permission denied? – Uncle Billy Feb 23 at 2:17
  • It's likely a combination of your shell, kernel and other stuff. On my machine (CentOS 7) I don't get any error at all. There could be timing issues at play as well. It's possible some kernel will spot the closed write side and give an EPERM for an attempt to open the closed filehandle. FWIW, with ksh93 it picks the lowest unopened handle (/dev/fd4) so we're definitely in the space of "lots of unknowns". Although it's very possible the OP also had bad command syntax and was trying to execute the path! – Stephen Harris Feb 23 at 2:22
  • I'm not the OP; see my comment for a better IMHO explanation of the OP's error. – Uncle Billy Feb 23 at 2:26
  • It's likely the OP had more than one error in their code; trying to execute the fd path and also expecting to read the input twice :-) It's why I originally asked if they meant one=$(...) and answered assuming good code syntax :-) – Stephen Harris Feb 23 at 2:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.