Path: utzoo!utgpu!water!watmath!uunet!tut.cis.ohio-state.edu!YALE.ARPA!ram-ashwin
From: ram-ashwin@YALE.ARPA (Ashwin Ram)
Newsgroups: gnu.emacs
Subject: Re: A find-file Hack
Message-ID: <8810261358.AA12325@ATHENA.CS.YALE.EDU>
Date: 26 Oct 88 13:58:06 GMT
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: Ram-Ashwin@yale.arpa (Ashwin Ram)
Distribution: gnu
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 31

> From: birdland!rberlin@sun.com  (Rich Berlin)
> 
> To simulate ls -l using file-attributes is certainly possible, but
> since there doesn't seem to be an elisp-interface to getpwent, you
> have to search /etc/passwd for the uid number (and punt or do
> something else ugly if you're using a name server like NFS, where the
> entry may not be in /etc/passwd....)  On my machine (a Sun 3/160,
> 12MB, running 4.0), using /bin/ls is acceptably fast and a lot easier.
> 
> But, now I am thinking about trying to support the getpwent function.
> Opinions (especially from RMS) about the practice of adding interfaces
> to system calls?  It certainly raises the risk of writing
> system-specific emacs extensions!

In this particular case, it doesn't really matter since you don't usually
want to see the uid when you find a file.  Presumably the attributes you're
interested in are the file type, protections, write dates, etc.

But in general, I think it's a bad idea to write code that depends on stuff
like (call-process "/bin/ls" ...).  Invoking OS-dependent system commands is
non-portable, not to mention difficult to read and debug, esp. for non-OS-hackers.
I think Emacs should provide functions like file-write-date, file-type,
file-attributes, etc., which is what other functions should be written in
terms of.  Internally, these functions can invoke the appropriate system
functions.

If a well-defined, high-level and relatively complete interface to system
functions is provided, this _reduces_ the risk of users hacking up their own
system-specific Emacs extensions.

-- Ashwin.