Subject: Re: Using Lisp to Call another program in linux?
From: Erik Naggum <>
Date: 11 Nov 2002 04:13:12 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Scott Schwartz
| It's just that I'm willing to settle for 90% portable.

  In that case, Common Lisp is not known to comply.

| I don't understand why all the unix lisp implementors cannot agree on
| what to name the lisp interface to the standard function for running
| another program on unix.

  Neither can I.

| While you are happy to nit-pick this into oblivion, perl and python
| have posix packages and get the job done with no fuss at all.

  What truly amazes me is that you do not understand that Perl and Python
  are /only/ implemented on POSIX systems and have no specification at all.

| > | but one that would require the lisp community to recognise that there is
| > | a standard, portable, API, that's almost always available, certainly
| > | available if you're running on any form of unix or windows.
| > 
| >   But Common Lisp does not thusly limit itself.
| Having a posix package, whereever possible, would not limit Common Lisp.
| It would make it much more useful, though.

  Look, is this really hard for you?  Common Lisp is not limited to running
  on "any form of Unix or Windows", /meaning/, it runs on /more than/ Unix
  and Windows and it cannot limit standard functionality that which works
  on Unix and Windows because of Posix.  Why do you think we have pathnames
  instead of simply using strings?  I assume you favor removing them, like
  some of the people working for a well-known Common Lisp vendor do, but
  that does not change the fact that Common Lisp is supposed to be portable
  to /more/ systems than those that can conveniently work with strings.

  One thing I cannot understand about Unix is why they were so incredibly
  stupid as to use slash-delimited "strings" in the system call interface,
  which makes it impossible even to quote the slash if it is desired in a
  filename.  This is so fucking unbelievably retarded that the morons who
  thought this up should have been shot.  The solution is /really/ simple.
  Instead of a string with slash-delimited components that the kernel has
  to hack up into substrings, convert all non-escaped slashes to NUL bytes
  in the caller and thus use the illegal NUL for both directory and string
  terminator.  An initial NUL byte would mean the pathname is absolute.
  The first empty string to follow in the list of strings would terminate
  the pathname.  (That is, two NUL bytes instead of one.)  This would allow
  the entire character set to be used in filenames and nobody would have to
  be mortally afraid of any other character encoding that could clobber the
  magic #x2F byte value.  This braindamaged aspect of the Unix design shows
  what kind of simple-minded approach these guys took to their types.

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.