Re: capabilities and POSIX ``emulation''

[Ivan Shmakov]

>>>>> Marcus Brinkmann <address@hidden> writes:

[...]

 >> Similar problem exists in passing the file descriptor from the
 >> parent process to the child.  That's no problem if it's a standard
 >> descriptor -- 0, 1 or 2 (stdin, stdout, stderr), but the programs
 >> commonly used aren't able to interpret any other descriptor they
 >> get.  That's how it's solved by Bash on GNU/Linux system:

 >> $ cat <(echo hello,) <(echo world\!)
 >> hello,
 >> world!
 >> $ 

 > Nice.

        The main idea was to use a similar approach to let POSIX
        programs /see/ the capabilities passed to them with the help of
        some shell construct.  I'm not familiar with GNU/Hurd system
        (nor with what it's supposed to be), so I'm asking for comments
        here.

 >> Would the implemented ``capabilities namespace'' be global, the
 >> following will also be possible, given the <(...) construct be
 >> implemented using the capabilities as well:

 >> $ emacsclient <(echo hello,\ world\!)

 > No, it wouldn't, as bash would still create a pipe for this, and
 > emacs can't edit a pipe, presumably because it needs random access to
 > the file.

        It's a different matter.  Currently, it won't work because
        <(...) construct returns a path which is ``local'' to the shell
        process (its meaning could be inherited by the child, but not
        passed to some arbitrary process).

        What to pipes, Emacs reads the whole file and puts its contents
        into a buffer.  On save-buffer, the whole buffer gets written to
        the file associated with it.  So, I see no particular reason to
        disallow reading of pipes, although in practice my Emacs seem to
        dislike this.