I wrote a kind of information search engine originally in bash. To
teach myself lisp, I've tried to translate the code using clisp, gcl,
and cmucl. Here's part of the code:
===============================
(defun preliminary-search ()
(princ "PLEASE ENTER SEARCH WORDS.")
(terpri)
(princ "===> ")
(setq search-word (read-line))
(if (equal search-word "")
(quit)
(progn
(system
(concatenate 'string "glimpse.word " search-word)))))
==============================
For the moment, please ignore the system function. I've defined it
differently for the 3 lisps.
The problem is at the read-line. When clisp is loaded separately, the
code works fine. However, when I load the code in xemacs, with ilisp,
clisp will show the request for search words momentarily, than exit.
Under gcl, I get the request and then an immediate exit in both solo
mode and in ilisp.
Only under cmucl does this code work correctly in solo mode and in
xemacs with ilisp.
I'm using linux with debian 2.0 and 2.1 apps. My version of ilisp is
5.8a, xemacs 21.1.
Conceptionally wise, I believe that something causes read-line to read
an immediate #\Newline, but why (and why would someone mess with
something as basic as an input statement?).
Any ideas are greatly appreciated,
i.b.
IBMackey <····@stic.net> writes:
> I wrote a kind of information search engine originally in bash. To
> teach myself lisp, I've tried to translate the code using clisp, gcl,
> and cmucl.
There is no uniform model of how Lisps deal with standard-input,
standard-output, etc. You should not assume that you either are or
are not connected to the console. You have to reach each vendor's
documentation. Some of these lisps are probably reading from stdin
and some are probably reading from /dev/ttyN (or whatever you call
the terminal--I'm not that savvy in the specific device terminology).
You *might* get better effect by explicitly doing
(read-line *terminal-io*)
or
(read-line *query-io*)
instead of trying to read from *standard-input* which is not guaranteed
to be an interactive stream. I'm not positive that will win, but
I think it will have a better shot.
Really, though, look in CLHS for definitions of these streams and you'll
see this is a vague area, but that *terminal-io* has more constraint on
it than *standard-input*. The default arg to read-line is *standard-input*.
CLHS can be found at
http://www.harlequin.com/education/books/HyperSpec/FrontMatter/index.html
Go to the symbol index and look for
*standard-input*
or
*terminal-io*
under the regular index for "non-alphabetic" or under the
permuted index for "S" (for *standard-output*) or "T" (for *terminal-io*).
IBMackey <····@stic.net> writes:
<
<
< I wrote a kind of information search engine originally in bash. To
< teach myself lisp, I've tried to translate the code using clisp, gcl,
< and cmucl. Here's part of the code:
<
< ===============================
< (defun preliminary-search ()
< (princ "PLEASE ENTER SEARCH WORDS.")
< (terpri)
< (princ "===> ")
< (setq search-word (read-line))
< (if (equal search-word "")
< (quit)
< (progn
< (system
< (concatenate 'string "glimpse.word " search-word)))))
<
< ==============================
< For the moment, please ignore the system function. I've defined it
< differently for the 3 lisps.
<
< The problem is at the read-line. When clisp is loaded separately, the
< code works fine. However, when I load the code in xemacs, with ilisp,
< clisp will show the request for search words momentarily, than exit.
<
< Under gcl, I get the request and then an immediate exit in both solo
< mode and in ilisp.
<
< Only under cmucl does this code work correctly in solo mode and in
< xemacs with ilisp.
<
< I'm using linux with debian 2.0 and 2.1 apps. My version of ilisp is
< 5.8a, xemacs 21.1.
<
< Conceptionally wise, I believe that something causes read-line to read
< an immediate #\Newline, but why (and why would someone mess with
< something as basic as an input statement?).
<
< Any ideas are greatly appreciated,
<
< i.b.
You could try listening/clearing the input stream before calling
readline, also using setq may have cause the value of `search-word' to
have a value of `""' on the second call to your function; try using
let instead.
(defun preliminary-search ()
(format *terminal-io* "~&Please enter search words.~%===> ")
(force-output *terminal-io*)
;; Clear the input stream - this should not be necessary.
(loop while (read-char-no-hang *standard-input* nil))
;; Use let to bind `search-word' to the input
(let ((search-word (read-line *standard-input*)))
(cond ((equal search-word "")
(quit))
(t (system (concatenate 'string "glimpse.word " search-word))))))
You could replace *terminal-io* with *standard-output* instead. The
above example works in emacs-19.34 with Allegro CL Trial Edition 5.0
[Linux/X86] (7/14/99 11:05), when system is defined as
(defun system (x) (print x)),
and quit defined as,
(defun quit (&rest args) (apply #'exit args)).
* IBMackey <····@stic.net>
| The problem is at the read-line. When clisp is loaded separately, the
| code works fine. However, when I load the code in xemacs, with ilisp,
| clisp will show the request for search words momentarily, than exit.
it's probably because there is a newline still unread after the form that
called the function. call LISTEN to see if there is anything there, and
print that out if there is. use READ-CHAR-NO-HANG to gobble up all of
these. this has the same effect as CLEAR-INPUT, so you might want to
gobble up only a small number of characters, like the newline, only.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?