Version: unspecified (using KDE 4.6.2) OS: Linux Process substitutions are generally mishandled by KDE applications. Reproducible: Always Steps to Reproduce: Some examples: $ kate <(xclip -o) ...snip... kate(30848)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/dev/fd/63" (Kate loads and shows a blank buffer) $ kompare <(curl -s 'http://bugs.gentoo.org/attachment.cgi?id=268673') $(equery w dev-lang/ocaml) (no error, but only shows a blank file in place of curl output) $ rekonq <(curl -s localhost) Error: "When connecting to: file:///dev/fd/63" $ okular <(man -t bash) okular(1610)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1610)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1610)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1610)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1610)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1610)/okular (app) Okular::Document::openDocument: No plugin for mimetype '"inode/fifo"'. Okular pops up "Could not open /dev/fd/63" The following does work correctly, but either should be fine. Not all programs accept "-" nor is it as versatile: $ man -t bash | okular - Expected Results: Programs should read/write pipes as though they were files. Process substitution creates a named pipe under /dev, runs a command, connects stdout or stdin to the named pipe, and places the fd of the pipe in a positional parameter of a command. This allows programs which read or write files to do so directly to a command pipeline. The exact behavior is platform dependent. The syntax is: $ cmd <(cmds) or $ cmd >(cmds) http://www.gnu.org/software/bash/manual/html_node/Process-Substitution.html#Process-Substitution
I am not sure if this can be supported/fixed KDE-wide. If at all, probably kio would have to support it. Otherwise I fear this has to be reported and fixed for each application where applicable.
I assumed this was probably a kio issue at least in many cases since it looks like KDE has some odd way of hooking into xdg-open to do it's own automagic MIME resolution to handle special URI schemes (man://, info://, etc) and perhaps it falls back to binutils "file" if that fails and doesn't default to treating "inode/fifo" specially. The problem with having that middleman I suppose would be programs that blindly expect to have the FD of a real file object held open in read/write mode depending upon how deep the abstraction provided by KIO really goes.
I'd say it'll have to be fixed per app. FWIW, kate/kwrite have a --stdin command line option. Closing as not a bug, for lack of a better option, it's not a bug in KIO, rather a wish list per app.