If I do:

at -f <(echo "rm $file") now + 2 hours

that works fine

However if I do this:

sudo at -f <(echo "rm $file") now + 2 hours

I get:

at: /dev/fd/63: No such file or directory

I assume this is because of the order the commands are processed. Is there any way to get around this using the sudo command? Only way I can think of is to put the command on a script and sudo that script which is an option, but now I want to know why this happens.

Apologies if this was answered somewhere already, I just can't find it as I am not sure what to look for.


Because the shell opens the pipe to the command in the <(...), and passes the file handle to the child process it runs, sudo in this case. The path /dev/fd/63 is a method provided by the kernel to allow access to an already open file handle through a normal pathname.

However, sudo doesn't pass the handle on to the process it runs (for security reasons): by default it closes all file handles except stdin, stdout and stderr, so the program that eventually runs doesn't have the file handle corresponding to /dev/fd/63 and it errors out.

You can solve it by doing the substitution in a shell within sudo:

sudo bash -c 'cat <(echo something)' 

This, of course means that the inner substitution also runs with elevated privilege:

$ sudo bash -c 'cat <(id)'
uid=0(root) gid=0(root) groups=0(root)

the -C flag for sudo offers another way, but it may need extra configuration to be allowed:

-C num, --close-from=num
Close all file descriptors greater than or equal to num before executing a command. Values less than three are not permitted. By default, sudo will close all open file descriptors other than standard input, standard output and standard error when executing a command. The security policy may restrict the user's ability to use this option. The sudoers policy only permits use of the -C option when the administrator has enabled the closefrom_override option.

|improve this answer|||||

I assume your intention is to cat all the files as root, of your current ls?

Could be smart to use xargs pipe instead. Try with this:

ls | xargs sudo cat

|improve this answer|||||
  • No, that was just an example to make it simple. I am interested in knowing why the file descriptor is not processed by sudo to apply it to something else. – Ulukai Nov 4 '16 at 13:59
  • Ah, my mistake; thought you wanted a workaround for your specific answer ("is there any way to get around this..") :) – Iskar Nov 4 '16 at 14:05
  • Sorry, I should have been more specific, I changed the command to make it clearer why I needed that. – Ulukai Nov 4 '16 at 14:09

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.