I suspected meld needed them to be also writable. However, it does say Could not read file (notice "read"); plus then the implication would be that they are writable for root, because there was no such error for root.

~$ diff <(echo foo) <(echo bar)
< foo
> bar

~$ meld <(echo foo) <(echo bar)  # not working, see comment below
~$ sudo -s
~# meld <(echo foo) <(echo bar)  # works just fine

The first one returns Could not read file and [Errno 2] No such file or directory: '/dev/fd/63'.

What do you suspect is the reason for this behavior?


Unprivileged user above, root below.

Screenshot, root

  • 1
    wait what? I would have expected sudo to mess with the process substition, but this is exactly the other way around? What does that meld program do? What happens if you just go cat <(echo foo) and sudo cat <(echo foo)? The first one should probably work if that diff does... – ilkkachu Dec 1 '17 at 9:17
  • I "cheated" a little. I didn't realize there would be a difference. Fixing it. Thanks for pointing it out. – glarry Dec 1 '17 at 9:23
  • @ilkkachu How do you solve the sudo cat <(echo foo) problem by the way? – glarry Dec 1 '17 at 9:28
  • @Stephen Kitt It used to work for me too. Is there any way for me to be using sudo meld without knowing? Something happened to my system since a few days ago. – glarry Dec 1 '17 at 9:43
  • Oh, it works from the text terminal (with export DISPLAY). I guess this means it works from a login shell. – glarry Dec 1 '17 at 9:50

This happens when a Meld window is already open. In that case, running meld again tries to use the existing Meld process; but that process can’t access the /dev/fd files which are used for the substitution...

There doesn’t seem to be an option to force Meld to use the “new” process, ignoring all others.

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.