lisp shell ala scsh
Lynn H. Quam
after scsh: the "scheme shell"? I have made considerable use of
scsh to avoid the cruftyness and limitations of Unix shells,
and to gain the power of a lisp-like programming language for
scripting.
The main features of scsh that I would like to see in Common Lisp are:
1) A more complete interface to the Posix system calls.
2) The simple but powerful process notation provided by scsh.
If nobody has made a serious attempt to implement these features,
perhaps I should persue it.
Coby Beck
Lynn H. Quam <qu...@ai.sri.com> wrote in message
news:59db34a7.02052...@posting.google.com...
Never tried it, but Clisp offers something like that.
http://clisp.cons.org/clash.html
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Christopher Browne
Both CLISP and CMU/CL have fair interfaces to POSIX system calls,
which ought to make 1) a matter of a bit of macrology, at worst.
If you were to build up some set of functions/macros to make it
convenient to use one or the other as a command shell, I'm sure people
would look at it with interest.
Make sure that you have item 3)...
3) readline-like interface so that it doesn't have to run inside Emacs
to allow the user to interactively select old commands to modify and
re-run them. [CLISP often has readline linked in, so this may come
"for free;" there's a package that does much the same for CMU/CL, so
this isn't nasty details at all...]
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/lisp.html
We all live in a yellow subroutine, a yellow subroutine, a yellow
subroutine...
Scott Schwartz
> Never tried it, but Clisp offers something like that.
Just playing around with clisp a bit, it doesn't seem to me to be
particuarly usable as a unix tool (compared to awk, perl, tcl,
python). For example, it prints (all?) diagnostic messages to stdout,
instead of stderr, so you cannot use it in a pipeline:
$ clisp -q -x '(defun foo () (princ "hello")) (foo)' | tr a-zA-Z X
XXXXXXXX
"XXXXX"
Obviously, -x would be much more useful if it didn't print the value
of the expressions at all.
$ perl -e 'sub foo {print "foo\n"} foo;' | tr a-zA-Z X
XXX
Worse, sometimes clisp will decide to enter a repl, even when the
manpage says that it won't:
$ clisp -q a.l
*** - Program stack overflow. RESET
[1]>
That would be a catastrophe in a pipeline.
Lynn H. Quam
"scheme shell", or any of its major components?
I have made considerable use of scsh to avoid the cruftyness and
limitations
of the various Unix shells, and to gain the power of a complete
programming language for scripting. For various reasons, I would much
prefer to use a Common Lisp based shell than scsh.
The primary aspects of scsh that I find attractive are and would like
to see
implemented for Common Lisp are:
1) A more complete interface to the Posix system calls. Common Lisp
is
missing lots of functionality in this area.
2) A powerful, but simple to use, process control notation.
If nobody has made a serious effort to implement these aspects of scsh
in
Common Lisp, perhaps I should. I realize that much of the work
involved is
OS and CL vendor FFI specific, and that it is non-trivial to make this
happed
for all Lisp on all OSes.
Any comments would be appreciated.
Erik Naggum
| Has anyone attempted to implement a "lisp shell" based on scsh, the
| "scheme shell", or any of its major components?
Yes. In-house only, called CLUNIX. It started out as a collection of
various abstractions of the horrible mess that was package management and
system administration databases and control variables, then got a little
shell. Then it godt stuck in missing a crucial piece, CLEMACS, which,
after a long time of study and research was basically relegated to my
next life (provided I don't come back as a cat, which I would like). The
reason for this is non-obvious. I am not a huge fan of job control as
BSD has implemented it, because I want processes output to be in their
own space (buffer), to be seen as "values" of programs, and I wanted to
keep them around, not just print them on the terminal _or_ pour them down
some drain (pipe), as well as controlling the destination buffer of more
than one file descriptor. E.g., if you have typed a program name, you
might know it has a --help option, but deleting your input line to type
that and maybe look at it while you produce a new command, has both
interrupted your work flow, it has filled your precious terminal space
with junk information, which you should be able to remove once you are
doing with it. Likewise, tracing something or requesting verbose running
or shell scripts, would naturally go in a different buffer while ordinary
output went in an undiluted window. Now the "exitcing" part, I wanted
input to be a dialog between the input system and the program, such that
as much pre-processing could be done in the shell as possible. (This
harkens back to the TOPS-20 CMND JSYS, for those familiar with it, where
te exec (command processor) actually called the programs with defined
entry points in order to run application code in order to instruct the
input parser. I probably made it less than obvious why it is brilliant
with this brief statement, so just trust me.) Unix can only fake this by
running the program with various half-standardized options, so I had
hoped to combine some of Emacs interactive form to communicate this kind
of information to a top-level user. All in all there were far too many
"good idea" in CLEMACS to keep my concentration, and it was turning into
one of those projects that, if it were ever completed, your life would
suddenly find itself devoid of meaning. However, I am still young.
| If nobody has made a serious effort to implement these aspects of scsh in
| Common Lisp, perhaps I should. I realize that much of the work involved
| is OS and CL vendor FFI specific, and that it is non-trivial to make this
| happed for all Lisp on all OSes.
Serious effort would be required to make this _not_ be its own full
implementation of Common Lisp. As I see it, it has some properties of a
full-blown window system. And well know how much work _that_ is. But
rob Bill Gates of a billion for me, and we can work something out.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Joe Marshall
"Erik Naggum" <er...@naggum.net> wrote in message news:32316997...@naggum.net...
>
> Serious effort would be required to make this _not_ be its own full
> implementation of Common Lisp. As I see it, it has some properties of a
> full-blown window system. And well know how much work _that_ is. But
> rob Bill Gates of a billion for me, and we can work something out.
Not to start a bidding war, but I'd do it for a couple of orders of
magnitude less....
Sam Steingold
> * On the subject of "lisp shell ala scsh"
> * Sent on 29 May 2002 14:39:16 -0700
> * Honorable qu...@ai.sri.com (Lynn H. Quam) writes:
>
> Has anyone attempted to implement a "lisp shell" based on scsh, the
> "scheme shell", or any of its major components?
check out <http://clisp.cons.org/clash.html>.
this is not _quite_ what you want, but it's a good start.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Your mouse has moved - WinNT has to be restarted for this to take effect.
Christopher Browne
>> * In message <59db34a7.0205...@posting.google.com>
>> * On the subject of "lisp shell ala scsh"
>> * Sent on 29 May 2002 14:39:16 -0700
>> * Honorable qu...@ai.sri.com (Lynn H. Quam) writes:
>>
>> Has anyone attempted to implement a "lisp shell" based on scsh, the
>> "scheme shell", or any of its major components?
>
> check out <http://clisp.cons.org/clash.html>.
> this is not _quite_ what you want, but it's a good start.
What's needed is to add some function/macrology to allow treating:
gunzip < paper.tex.gz | detex | spell | lpr -Ppulp &
with something like:
(& (| (gunzip) (detex) (spell) (lpr -Ppulp)) ; background a pipeline
(< paper.tex.gz)) ; with this redirection
The scsh folks have come up with a pretty nice set of notation for
describing how to link processes together... Imitation wouldn't be
the worst thing in the world...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/languages.html
"Everything should be built top-down, except the first time."
-- Alan Perlis
Lynn H. Quam
>>> As I see it, it has some properties of a full-blown window system.
Apparently Erik is not familiar with scsh. My objectives have nothing to do
with making any kind of window system,fancy user interface, or implementation of
Common Lisp.
Let me briefly expain the idea:
1. Start with an existing Common Lisp implementation such as CMUCL or Allegro
CL.
2. Using the foreign function interface (FFI) of the CL implementation, augment
the set of POSIX system calls that are available from CMUCL to include those
available to scsh. In scsh these include:
file-symlink?, file-regular?, file-owner, read-symlink, ...
(I realize that file-symlink? and read-symlink are not POSIX, but ...)
3. Implement the process notation used by scsh for easily implementing process
pipelines, I/O redirection, etc. The main problem here is that the scsh
reader is case sensitive so the scsh process form:
(run (ls -l /etc))
is equivalent to the Unix shell command:
ls -l /etc
In Common Lisp (except for case sensitive Allegro), one would either have to
say:
(run `("ls" "-l" "/etc"))
or possibly introduce a new reader macro #` (sharpsign-backquote) that does
backquote reading in a case sensitive manner:
(run #`(ls -l /etc))
There are serious complications with the introduction of case sensitive
read. What should the following do?
(run #`(ls -l ,foo))
where foo is a lexxically bound variable. Is the reading of foo case
sensitive? I think that it should no be. Therefore, the comma (,) reader
macro within case sensitive reading must revert to case insensitive mode.
Erik Naggum
| Apparently Erik is not familiar with scsh.
Apparently Lynn is not familiar with the simple question, as opposed to
making statements about other people from a lack of understanding. So I
would like to tell you about the simple question, Lynn. It works like
this: You arrive at some assumption by guesswork, impression, believing
what appears to be, or outright confusing what appears to be with what
is, unless, of course, you just make it up. Regardless of origin, it is
your assumption. It is not yet true for anybody else, nor about anything
else. This is very fundamental. Just because you believe it does not
make it so. I hope I shall not have to repeat this more forcefully, but
it really is _the_ crucial point: Because things do not magically turn
into whatever we believe, there is sometimes, often, or always (depending
on the type of assumption) a need to check whether what we believe and
what is really so are approximately the same. This is generally called
the correspondence theory or truth, in case you do not believe me and
need to look this up. (If you are too well educated for your own good,
you will now quibble over how good these approximations really are, or
perhaps argue against the correspondence theory with some version of the
coherence theory, but please lay that to rest for now. The point is
simply that there is no known causal link between "you believe" and "it
exists". I hope this is sufficiently non-controversial that you are not
derailed by this, and also assume that you are not a magician or mystic
or alchemist who enjoys making new reality just because you feel like it.
This is, after all, comp.lang.lisp.) You see, before you can go ahead
and _use_ an assumption, as in _act on it_, you need to see if by doing
so, you cause a need to correct your assumption or your actions, or even
put you in a correctional facility, which is wasteful towards others.
When you act on assumption alone, to some extent, you force your view on
reality on other people. Most people will reject this with a hostile
reaction. I have resolved not to be hostile to people who are instead
clearly lacking in basic knowledge of how language in particular and the
world in general works, but to take the time to offer my best effort to
educate them in such simple matters. After all, they are probably
educated by the American educational system and as CNN reported recently,
fully 70% of the American population do not understand the scientific
process at all. So, part of the scientific process is to come up with
credible assumptions, making predictions from them that can be easily
tested, and, get this, test those predictions to the best of your ability
_before_ you claim that your assumption is true. If this is generally
employed by more people, it would most probably cause a lot less friction
among them, because some people, such as Lynn, who is not only wrong, but
quite condescending in their assumption, would have to make it clear that
their ill-founded guesswork was just made up in order to be hostile and
condescending and generally a party-pooper. Shedding light on how their
assumptions arose would put the responsibility back where it belongs.
However, in this case, we have some clear evidence that Lynn H. Quam is
unfortunately unskilled in the relatively simple process of making an
assumption more than guesswork and appearances, and we may make an
assumption that Lynn simply lacks the ability to introspect sufficiently
to see that what he assumes is much more a product of his perceptions
than any actually verifiable facts. Lacking clear evidence, however,
this must remain an assumption.
However, returning to the simple question. Instead of pretending that an
assumption is true, Lynn could have tested the assumption by _asking_.
This is harder than it looks for people who think they know everything,
but it generally involves rotating the word order slightly and placing a
'?' at the end of a sentence, spoken with a slightly raised pitch at the
end of a sentence. (Lynn, you should be able to find someone close to
you who can teach you how this sounds; this medium is insufficient for
this.) A simple question communicates "I do not know whether what I
assume is actually so". It is quite honest and also tries to communicate
that you would _like_ to know. (This in contrast to the hostile questions
that more than anything else communicate "I know that what you assume is
not actually so".) In this case, Lynn could have formulated a simple and
honest question like this:
Are you familiar with scsh?
The only problem with this question is that it looks very much like one
of those hostile questions, because it is fantastically unlikely that
anyone would not be familiar with scsh if they were working with shells
of any kind on Unix. But this is, of course, the whole point with Lynn's
statement of assumption that pretends to be fact. For all the ability to
be hostile and condescending, Lynn has not communicated _any_ desire to
learn, so perhaps the simple question should be abandoned as an approach.
Trying more than one approach is always good, since it can often lead to
better assumptions and better questions.
Could it be that Lynn is so gravely mistaken in the perceptions of what I
have written that _no_ assumptions with a reasonable correspondence with
reality could have emerged even if more effort went into it, even if many
questions were asked? Now we are looking at the problem of arrogance
that so often comes with pretending that something you just made up is
actually true. However, this is just an assumption, and although it is
far more likely that I am right than that Lynn is right, we must test it
in order to see whether we can base any action on it. Therefore, the
assumed misunderstandings must be exposed and clarified. There is only
one way to find out, since the only person who has made the assumption is
Lynn.
So, Lynn, was it anything in what I said that _both_ caused you to assume
that I was not familiar with scsh _and_ caused you to discard all other
possible explanations for what you saw? I am just _dying_ to know,
because, frankly, it looks very much like you have no grounds at all for
either your assumption or the arrogance that comes with it. But that is
just appearances to me. If you answer my simple question, we can shed
some light on your need to post your assumptions as if they were facts,
and perhaps even learn not to do it again. That would be very nice.
Kragen Sitaker
> 3) readline-like interface so that it doesn't have to run inside Emacs
> to allow the user to interactively select old commands to modify and
> re-run them.
Wouldn't it be easier to raise an error on startup if environment
variable EMACS is not set to 't'?