Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR)
Newsgroups: comp.lang.perl
Subject: Re: ftok() ?
Message-ID: <1990Nov3.015521.24437@NCoast.ORG>
Date: 3 Nov 90 01:55:21 GMT
References: <1990Oct30.123536.12798@robobar.co.uk> <10178@jpl-devvax.JPL.NASA.GOV>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR)
Followup-To: comp.lang.perl
Organization: North Coast Public Access *NIX, Cleveland, OH
Lines: 22

As quoted from <10178@jpl-devvax.JPL.NASA.GOV> by lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall):
+---------------
| In article <1990Oct30.123536.12798@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
| : simply perversity that ftok() is left out? :-)
| 
| I don't know if it's perversity--more like nobody thought about it.  From
| the man page, though, it looks as though it does little more than encode
| the device and inode of the file along with the id character you pass.
| I bet it's a one line perl subroutine.
+---------------

As long as you use the same algorithm as the real ftok(), at least.  I have
programs that expect to "accept connections" on certain "well-known" shared
memory objects, e.g. ftok(ttyname(1), 'c') to view and alter csl and cslmsp
configuration.

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY