[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: capabilities and POSIX ``emulation''
From: |
Ivan Shmakov |
Subject: |
Re: capabilities and POSIX ``emulation'' |
Date: |
Tue, 28 Mar 2006 00:19:26 +0700 |
>>>>> 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.