run.c translator

[Marcus Brinkmann]

Hi,

I have cleaned up my run.c translator for inclusion in the Hurd,
please let me know if I can check it in (it's supposed to be a single file
in trans/run.c).  I think it is a simple translator to learn from by
beginners, but it also provides a useful functionality.  It's one piece that
bridges between the Hurd filesystems and UNIX programs.

It supports reading and writing, through a bidirectional pipe (but it will
only set up the directions that correspond to the open() flags).  One simple
way is to use it to connect a file to the output of a program:

$ settrans -ac ~/.signature /hurd/run -r /games/fortune -s

Another simple way is to direct what is written into a file to program:

settrans -ac /var/log/apache.log /hurd/run -W /bin/sh -c 
'/bin/logfile-dispatcher > /tmp/dispatcher-status'

In this sense, it can also be an alternative to James filemux, because you
can connect it with arbitrary programs, like shell scripts (for example, in
read mode, you can make a shell script that selects a file at random from a
group of files, and outputs it).  One instance of the program is started for
each open which is followed by a real file action (like a read or write).

One special mode that doesn't work too well is using it in read/write mode.
If you open it in read/write mode, you can communicate with the program over
its stdin and stdout descriptors (almost as with pipes), and use the program
as filter.  For example, it is supposed to be possible to do things like
that:

settrans -ac /tmp/foo /hurd/run /bin/tr a-z A-Z

However, I have not found an easy way yet to route data through the /tmp/foo
node.  The shell redirector <> looks promising, but I am not sure if it is
possible to incorporate this correctly into a pipe-chained sequence of commands.
So I am considering to write a "filter" program that has two threads and takes
a filename as an argument.  One thread reads on stdin and writes to the opened
file, the other thread reads from the file and writes to stdout.  This should
work rather well, and can be used like this:

cat text | filter /tmp/foo > /tmp/text-foo-ed

However, there is a fundamental problem in all this because we can't
properly signal an EOF condition.  After all, we only have one file
descriptor open to the run translator, and how can we signal that there is
nothing left to read to it?  When we could, I would use two pipes instead
one bidirectional, and close it.  This would be enough to let the running
program know about it.  But how to get the end of file signal to the foo
translator in the first place?  The filter program should do it somehow.
Do we have some icky (or even proper) RPC that we can use for this?  Am I
missing something obvious?

Another point is that it does not do any buffering.  It probably should,
although this would make it more complex.  Oh, and I have not tested the
icky select implementation.  I should probably use io_select as I use
io_readable, but I changed this back and forth for unrelated reasons.  Oh,
and I was not sure about the reply port argument and cancellation.  For
learning by newbies, I also think that having some code that looks familiar
is also nice ;)

I have tested that reading and writing and all options work properly. 
With programs like cat, the filter mode works properly.  With programs like
tr, it seems to hang when trying to read back (see above).

If you have any suggestions, please let me know.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de

run.c
Description: Text Data