Re: [PLUG] dynamic file (script output)

["Kyle R . Burton" <mortis@voicenet.com>]

> Though he didn't posit it very clearly, that doesn't really solve
> Martin's problem.
> 
> The point is that one might want to do this somewhere other than a
> shell. (In this instance, within an editor to slurp in a dynamic
> .signature, but I can envision other uses for the principle.) Even
> in vi's ex mode :!echo `date` doesn't get you very far (mostly
> because the output isn't read it). Yes, it's possible to write a vi
> macro to do this, but it gets *really* messy. (Try it, you'll see.)

:r!date

I think may acheive what you're thinking of in vi.

> As much distaste as I have for Richard Stallman and the HURD in
> general, this is a *really* nice feature. Directories can log every
> cd into them, files can overwrite themselves on every read (think,
> migratory .plan or web page image).

The only way I currenly know of how to get around the recycling timeout,
and incomplete output/execution problems with a FIFO would be to use
a kernel module and implement a device file.  Every time someone invokes
a file operation on the device file (like opening/reading/writing) the
module has the opportunity to react.  This allows you to write a module that
can have multiple simuntaneous processes reading from the device at the
same time and other things that are currently only acheivable via a
kernel module.

A good place to start looking for an example of this kind of functionality
would be with the module that implements /dev/urandom, which I beleive
is /usr/src/linux/drivers/char/random.c -- I'd probably start with
the following: random_read, random_read_unlimited, random_poll, random_write, 
and random_ioctl.  random_read and random_read_unlimited both call 
extract_entropy which actualy does the work of copying data from kernel
space to user space.  These functions are exported by the module in structures
used by the kernel: random_fops, and urandom_fops.  There are other
things you'll have to do to actualy implement a dynamicly loadable module,
but I'm no kernel hacker, so I don't really know any more than I've told
you already.


Good luck, and if you do implement this kind of thing, I'd be interestd
in seeing it.

k

-- 
------------------------------------------------------------------------------
"From a certain point onward there is no longer any turning back.  That is the
 point that must be reached."   -- Kafka
mortis@voicenet.com                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------


______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug