🚀 go-pugleaf

In article <978@bbt.UUCP>, rgs@bbt.UUCP (steinbeiser) writes:
|> Ok, how do you check the status of the file to see if it has
|> been open by someone else?  Its not obvious how (or if) stat() would do this.
|> Also, would the C program have to be running constantly in the background
|> someplace?

1. You open the pipe for write, and do a select() on it, and when you get an
   OK to write from select(), you know that someone has opened the other end.

2. Yes, it would have to be running constantly in the background someplace.

I suppose another thing you could do would be to write a program that talks
NFS, and mount it under your home directory (for kernels which support the use
of programs that speak the NFS protocol in this way), and then put a symbolic
link from your .plan into that filesystem -- when something tries to open your
.plan file, your NFS protocol program will get called and you'll be able to
claim whatever you want for the contents of the .plan file.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710

In article <1990Sep26.201406.12663@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>In article <978@bbt.UUCP>, rgs@bbt.UUCP (steinbeiser) writes:
>|> Ok, how do you check the status of the file to see if it has
>|> been open by someone else?  Its not obvious how (or if) stat() would do this.
>|> Also, would the C program have to be running constantly in the background
>|> someplace?
>2. Yes, it would have to be running constantly in the background someplace.

True.  (It's process wouldn't have to be RUNNING constantly, just present
constantly.)

>1. You open the pipe for write, and do a select() on it, and when you get an
>   OK to write from select(), you know that someone has opened the other end.
>
>I suppose another thing you could do would be to write a program that talks
>NFS, and mount it under your home directory (for kernels which support the use
>...

Ick.  Overkill, isn't it?

open()ing a FIFO for writing blocks until someone opens it for reading,
unless you have O_NDELAY set.  Try something like this with the Bourne shell
(I'm using SunOS 4.1):

/usr/etc/mknod foofo p
while true
do
date >foofo
done &

Now typing 'cat foofo' will print the date.  Each time the background subshell
tries to open the redirection file foofo, it will block until someone opens
it for reading.  So as soon as the open(2) call returns, you know
someone is accessing foofo.  As soon as the redirection file is opened,
the shell execs 'date', which pipes the date to whatever process is
catting foofo, and exits.

If Lafontaine's elk would spurn Tom Jones, the engine must be our head, the
dining car our esophagus, the guardsvan our left lung, the kettle truck our
shins, the first class compartment the piece of skin at the nape of the neck,
and the level crossing an electric elk called Simon.

In article <1990Sep26.201406.12663@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes:
> In article <978@bbt.UUCP>, rgs@bbt.UUCP (steinbeiser) writes:
> |> Ok, how do you check the status of the file to see if it has
> |> been open by someone else?  Its not obvious how (or if) stat() would do this.
> |> Also, would the C program have to be running constantly in the background
> |> someplace?
> 
> 1. You open the pipe for write, and do a select() on it, and when you get an
>    OK to write from select(), you know that someone has opened the other end.
> 

Or, in System V, quoting from the open(2) man page:

	When opening a FIFO with O_RDONLY or O_WRONLY set:

	If O_NDELAY is set:
		[ not relevant ]

	If O_NDELAY is clear:
		An open for reading-only will block until a process
		opens the file for writing.  An open for writing-only
		will block until a process opens the file for reading.

So all you have to do is make .plan a FIFO, and have a program open
it for writing (the program will have to be in an infinite loop, though).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzx.att.com    | They recommended
AT&T Bell Laboratories      | ...!att!mtgzx!dwex    |    euthanasia
200 Laurel Ave - 4B-421     |                       | For nonconformists
Middletown, NJ  07748       | (201) 957-5871        |    everywhere

I have tried every suggestion that has come along and nothing seems to work!
We are running Ultrix 4.0 on several DEC products.  It is Ultrix's finger?

Thanks, this sounds like too much fun to not be able to get working.


-- 
Jeffrey D. Parker (no philosopher) | By all means marry; if you get a good wife,
INET: parker@vela.acs.oakland.edu  | you'll become happy; if you get a bad one,
BITNET: PARKER@OAKLAND             | you'll become a philosopher.      Socrates
UUCP: ...!umich!vela!amiga1!fanatic| (Or get an AMIGA - You'll be Happy!)	

parker@vela.acs.oakland.edu (Jeff Parker) writes:

>I have tried every suggestion that has come along and nothing seems to work!
>We are running Ultrix 4.0 on several DEC products.  It is Ultrix's finger?

Yep, in 4.0 the finger program is smart enough to sense that .plan is
a named pipe and not a 'real' file.

On saturday Ultrix 4.0 was installed on our site and since saturday
the named pipe .plan doesn't work any more with finger :-(.
Try 'cat .plan' and you will see that the construct itself does work.

>Thanks, this sounds like too much fun to not be able to get working.


>-- 
>Jeffrey D. Parker (no philosopher) | By all means marry; if you get a good wife,
>INET: parker@vela.acs.oakland.edu  | you'll become happy; if you get a bad one,
>BITNET: PARKER@OAKLAND             | you'll become a philosopher.      Socrates
>UUCP: ...!umich!vela!amiga1!fanatic| (Or get an AMIGA - You'll be Happy!)	
-- 
Henk Fictorie, PTT Research Neher Labs,    H_Fictorie@pttrnl.nl
P.O. box 421,                              ...!hp4nl!dnlunx!henkf
2260 AK Leidschendam, The Netherlands      Phone    : +31 70 3326356 

In article <3194@vela.acs.oakland.edu> ...!umich!vela!amiga1!fanatic writes:
>I have tried every suggestion that has come along and nothing seems to work!
>We are running Ultrix 4.0 on several DEC products.  It is Ultrix's finger?
>
>Thanks, this sounds like too much fun to not be able to get working.
>
>

I am using Ultrix and have had little trouble.  The long C program worked just 
fine for use as long as it was in the background.  The shell script took
a little more care.  We would put a couple of echos or a ls within but
nothing too complex.

dwex@cbnewsj.att.com (david.e.wexelblat) writes:

| Or, in System V, quoting from the open(2) man page:
| 
| 	When opening a FIFO with O_RDONLY or O_WRONLY set:
| 
| 	If O_NDELAY is clear:
| 		An open for reading-only will block until a process
| 		opens the file for writing.  An open for writing-only
| 		will block until a process opens the file for reading.
| 
| So all you have to do is make .plan a FIFO, and have a program open
| it for writing (the program will have to be in an infinite loop, though).

I've found an interesting problem ... here's my situation.

Rich's code works all fine and well, but running it from the command
line caused it to die as soon as I log off.  So I modified the program
to fork(2) and return immediately (for my convenience in starting it)
as well as to ignore SIGHUP so it would stay running after logoff.

The problem is that the program works fine while I'm logged in,
displaying only one fortune per finger.  However, when I log off and
the process is inhereted by the system, it does NOT block on the write
to the pipe, but rather performs the write and buffers the output in
the pipe.  The upshot of all this is that while I'm logged out and the
plan proc is running, huge amounts of fortunes accumulate in my .plan
FIFO.

Is this behavior normal?  Or is there a problem with my flavor of
System V?

Thanks ...

Eric
--
       Eric Peterson <> epeterson@encore.com <> uunet!encore!epeterson
   Encore Computer Corp. * Ft. Lauderdale, Florida * (305) 587-2900 x 5208
Why did Constantinople get the works? Gung'f abobql'f ohfvarff ohg gur Ghexf.

In article <1990Sep28.154733.26346@cbnewsj.att.com> dwex@cbnewsj.att.com (david.e.wexelblat) writes:
>In article <1990Sep26.201406.12663@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes:
>> In article <978@bbt.UUCP>, rgs@bbt.UUCP (steinbeiser) writes:
>> |> Ok, how do you check the status of the file to see if it has
>> |> been open by someone else?  Its not obvious how (or if) stat() would do this.
>> |> Also, would the C program have to be running constantly in the background
>> |> someplace?
>> 
>> 1. You open the pipe for write, and do a select() on it, and when you get an
>>    OK to write from select(), you know that someone has opened the other end.
>> 
>
>Or, in System V, quoting from the open(2) man page:
>
>	When opening a FIFO with O_RDONLY or O_WRONLY set:
>
>	If O_NDELAY is set:
>		[ not relevant ]
>
>	If O_NDELAY is clear:
>		An open for reading-only will block until a process
>		opens the file for writing.  An open for writing-only
>		will block until a process opens the file for reading.
>
>So all you have to do is make .plan a FIFO, and have a program open
>it for writing (the program will have to be in an infinite loop, though).
>

There are a bunch of ways to handle this in C.  Doing a select is
really overkill.  The simplest way is to have a loop that looks 
something like:

	make fifo;
	loop forever;
		open FIFO for writing	/* This will block until 
					   someon opens it for reading */
		fork()
		if in child:
			exec a program
		if in parent 
			close FIFO
			wait for child;
		

I have a program called plan which takes one argument, the 
name of a program to exec as your plan.  This version inherits
your environment on the exec.  If anyone would like a copy
of the source, drop me a note.

-Tony