schwartz@shire.cs.psu.edu (Scott E. Schwartz) (02/21/90)
I noticed that perl doesn't have statfs. Is this something that should be handled by syscall or is it worth building in? Should it return a list like stat or take vectors like select? -- Scott Schwartz schwartz@cs.psu.edu "the same idea is applied today in the use of slide rules." -- Don Knuth
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/22/90)
In article <Ea1pdg@cs.psu.edu> 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