Subject: [clisp-list] run-program uses shell?

From: Peter Wood <[email-masked]>
Date: Sun, 15 Jul 2001 23:14:53 +0200

Hi

Is there some compelling reason that running programs has to go
through the shell? "(run-program ...)" is just a frontend for
"(run-shell-command ... :may-exec t)", right?  Is this purely for
portability reasons?

It's easy enough to run programs without /bin/sh using linux:fork and
linux:execlp*, but wait() is missing.  Is there some horrible,
insurmountable ffi thing with wait()?  How difficult would it be to do
a complete binding for wait() so all the WIF*(stat_val) stuff was
accessible from Lisp?

I want to use CLISP as _the_ shell, not as a frontend to /bin/sh.

Regards,
Peter

---

From: Sam Steingold <[email-masked]>
Date: 16 Jul 2001 12:03:33 -0400

> * In message <[email-masked]>
> * On the subject of "[clisp-list] run-program uses shell?"
> * Sent on Sun, 15 Jul 2001 23:14:53 +0200
> * Honorable Peter Wood <[email-masked]> writes:
>

it also saves you PATH handling.
and you should not underestimate the portability concerns...

> I want to use CLISP as _the_ shell, not as a frontend to /bin/sh.

/bin/sh is so small that this should not matter

Yes, is all you want to do is start other programs, CLISP is probably
_not_ the right tool.
CLISP is good for many other things though :-)

-- 
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
The program isn't debugged until the last user is dead.

---

From: Peter Wood <[email-masked]>
Date: Wed, 18 Jul 2001 07:50:23 +0200

> and you should not underestimate the portability concerns...

Well, if _my_ app is not going to be portable, I don't have to worry
about PATH handling.  Problem solved, for _me_.

> /bin/sh is so small that this should not matter

I am completely unconcerned with efficiency/speed issues.  I am
writing a Common Lisp Shell.  It can not depend on other shells for
what it does.

> Yes, is all you want to do is start other programs, CLISP is probably

A shell does more than run programs.

Regards,
Peter

---

From: Peter Wood <[email-masked]>
Date: Wed, 18 Jul 2001 11:14:41 +0200

> CLISP is good for many other things though :-)

To answer my own question:

It is not a problem adding wait() and waitpid() to linux.lisp.  I have
just done it.  Took about 20 minutes, including the remake.

The WIF*(stat_val) stuff is inaccesible, I think, but wait() itself
works fine, so now my shell can do

(with-fork (child-process) (parent-process))

And either have parent wait for child or not, as I choose, and without
the _fscking_ shell intermediary.  And with the option of easing the
syntax of run-program.

:-)

Regards,
Peter

---

From: Raymond Toy <[email-masked]>
Date: 18 Jul 2001 15:37:59 -0400

>>>>> "Peter" == Peter Wood <[email-masked]> writes:

    Peter> I am completely unconcerned with efficiency/speed issues.  I am
    Peter> writing a Common Lisp Shell.  It can not depend on other shells for
    Peter> what it does.

Why not?  While sh can do a fair amount, there are lots of things it
can't do without help.  So I don't see a problem with clisp needing sh
to do things.

But this doesn't really have anything to do with clisp anymore....

Ray

---

From: Peter Wood <[email-masked]>
Date: Thu, 19 Jul 2001 17:05:38 +0200

> can't do without help.  So I don't see a problem with clisp needing sh

Tell me which shell starts another (different) shell to run programs.

One reason it would be wrong is that you would have to have both
shells in /bin instead of only the one.  If Clash is to be able to run
bootscripts (rcscripts) it needs to be on the root file system.

Yes, disk space is cheap.  Yes, there are still good reasons for
having a small root file system.  Most people don't want redundant
stuff there.

All this just means that Clash will be Linux-only.  It makes life much
easier for me.

Regards,
Peter

Ps. The simpler syntax of execlp* means I don't need to use a
read-macro to process the user's input, and I can give the user the
illusion of having an identical syntax to simple shell commands.
That's a big plus, since people don't want to have to fiddle with
parentheses and #\# for simple commands.

---

From: Raymond Toy <[email-masked]>
Date: 19 Jul 2001 11:23:35 -0400

>> can't do without help.  So I don't see a problem with clisp needing sh

    Peter> Tell me which shell starts another (different) shell to run programs.

Well, I vaguely recall that old versions of sh *always* started
another copy of itself to run a program.  Perhaps that's still true.
Maybe csh calls sh to run shell scripts?  (At least someone has to do
that eventually when the script has #!/bin/sh.)  I do know that bash is
somewhat smarter in that it doesn't always do that and instead forks
and execs (or something like that) if it running a "simple" program.

In any case, I wasn't saying what you wanted to do was right or wrong.  I was
just curious on why you didn't want clisp to use sh.

    Peter> Ps. The simpler syntax of execlp* means I don't need to use a
    Peter> read-macro to process the user's input, and I can give the user the
    Peter> illusion of having an identical syntax to simple shell commands.
    Peter> That's a big plus, since people don't want to have to fiddle with
    Peter> parentheses and #\# for simple commands.

This is cool.  I've never had an interest in a lisp shell because the
ones I've looked at used lisp syntax and that doesn't make for a great
shell where you just wanted to run this program piped to that.  In
this case, shell syntax is nicer than lisp.  But for more complicated
things, having lisp is good.

Ray