Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Newsgroups: comp.lang.perl Subject: Re: statfs Message-ID: <7123@jpl-devvax.JPL.NASA.GOV> Date: 21 Feb 90 17:54:45 GMT References: Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 33 In article schwartz@shire.cs.psu.edu (Scott E. Schwartz) writes: : I noticed that perl doesn't have statfs. Is this something that : should be handled by syscall or is it worth building in? It could be handled by syscall, presuming you have syscall. I would consider adding it in if I decided that I could easily enhance the portability of Perl scripts by doing so--that is, if there are several ways to do it on different OS's and perl can present a single interface on all those machines. This is the primary reason I added mkdir and rmdir--some machines have the system call and some have to call /bin/mkdir and /bin/rmdir. (There's also the little matter of knowing how to implement it on the machines that don't have the system call. This would be a good project for someone who has access to some of the kinds of machines I don't have access to.) (There's the additional little matter of deciding what the interface should be--what fields should be returned, in what order. Especially since the system call itself may change in the future as new kinds of filesystems are supported.) : Should it return a list like stat or take vectors like select? Lists are preferred for anything that has named fields. Even the implementation using syscall would probably unpack to a list of names. Vectors are good for compact storage of arrays of anonymous integers (including 1 bit integers) but are otherwise somewhat foreign to the Perl paradigm. They're in there for two reasons. One is select. The other is that I'm planning on using them to implement article sets in the new rn, when I get around to writing it. Larry