capabilities and POSIX ``emulation''

[Ivan Shmakov]

        Well, following is some thoughts, some of which were discussed
        in the thread.

        The first side of the problem with presenting multi-interface
        (and multi-implementation) files to a program which uses the
        POSIX layer is that such files can't be adequately represented
        in the terms of POSIX.  However, it's the minority of programs
        that have the necessity to explore ``the true nature'' of the
        file they're asked to work with (e. g. `stat').  They should be
        replaced with their ``aware'' counterparts.

        The second side, closely related to the first one, is that there
        might be POSIX programs, which behavior depends on whether the
        given path represents a file, or a directory.  This problem is
        very similar to the ``symbolic links vs. files they refer to''
        case.  The same convention (using trailing slash to distinguish
        between symbolic link and the directory it points to) couldn't
        be used, since there could be paths, which are symbolic link,
        file and directory at the same time.

        The third side of the problem is that there might be a need to
        pass not only a specific interface, but the specific
        implementation to the POSIX program.  I'm not sure in using the
        term right, but it seems that the ``capability'' passed from one
        HURD process to the other could be implemented to posses a
        ``default view'', which the originating process could explicitly
        set.  Thus, the problem is in allowing POSIX programs to use the
        capabilities passed to them.

        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!
$ 

        When interpreting <(command) construct, Bash establishes a pipe
        between the command in parentheses and a child spawned for the
        ``outer'' command; the construct is replaced by the reference to
        the file descriptor in a per-process ``file descriptors''
        namespace, like /dev/fd/3:

$ echo <(echo hello,) <(echo world\!)
/dev/fd/3 /dev/fd/4
$ 

        Of course, there're cases when this very simple solution is not
        enough, e. g.:

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

        The problem with capabilities looks essentially the same: one
        process could pass capability to a POSIX process, but the latter
        won't notice, won't interpret and won't use it.  So, there
        should be a translator, implementing a namespace for
        capabilities.  This way, the method of specifying arbitrary view
        of the object could be implemented by the shell, e. g. like
        this:

$ touch ':(as_directory file.tar.gz)'
$ unaware-ls :(as_directory file.tar.gz)
foo
$ unaware-ls ':(as_directory file.tar.gz)'
:(as_directory file.tar.gz)
$ echo :(as_directory file.tar.gz)
/dev/caps/123
$ 

        And no compromise -- no more characters get reserved.

        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\!)