I am using Allegro. My lisp is talking to an interactive program using
run-shell-command, and the interactive program expects an eof character
to terminate my input to it. Is there a standard or a franz specific
way to generate a eof character using format, say?
Thanks a lot.
>I am using Allegro. My lisp is talking to an
>interactive program using
>run-shell-command, and the interactive
>program expects an eof character
>to terminate my input to it. Is there a
>standard or a franz specific
>way to generate a eof character using
>format, say?
If this program expects input to be terminated by EOF, then chances are
it expects to get its input from a file via input redirection like
this:
interactive.exe <input.txt
The standard way to provide the EOF (in any language, not just Lisp) is
to close the stream. If your program really is interactive, expecting
several rounds of input that are terminated by EOF chars.... that would
be very strange. Any idea why a program would be designed that way?
From: Robert Uhl
Subject: Re: probably trivial: what is the eof character?
Date:
Message-ID: <m3acjpilmu.fsf@4dv.net>
"remixer" <········@gmail.com> writes:
>
> I am using Allegro. My lisp is talking to an interactive program using
> run-shell-command, and the interactive program expects an eof
> character to terminate my input to it. Is there a standard or a franz
> specific way to generate a eof character using format, say?
You don't generate an EOF character--you end the file, by closing it.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I use shell scripts at ork. Some cow-orkers refuse to touch them,
their excuse is usually `I don't understand perl.' Their fear of perl
is such that all things unknown are also perl. --Andrew Dalgleish
"remixer" <········@gmail.com> writes:
> I am using Allegro. My lisp is talking to an interactive program using
> run-shell-command, and the interactive program expects an eof character
> to terminate my input to it. Is there a standard or a franz specific
> way to generate a eof character using format, say?
There is no EOF character. EOF is not a character, it's a condition.
[79]> (read-from-string "")
*** - READ: input stream #<INPUT STRING-INPUT-STREAM> has reached its end
[81]> (ext:shell "rm /tmp/a ; touch /tmp/a")
0
[[82]> (with-open-file (in "/tmp/a") (read in))
*** - READ: input stream #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/tmp/a" @1>
has reached its end
EOF means End Of FILE. So to "generate a EOF", you just close the stream.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
From: Duane Rettig
Subject: Re: probably trivial: what is the eof character?
Date:
Message-ID: <4slxhjyih.fsf@franz.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> "remixer" <········@gmail.com> writes:
>
> > I am using Allegro. My lisp is talking to an interactive program using
> > run-shell-command, and the interactive program expects an eof character
> > to terminate my input to it. Is there a standard or a franz specific
> > way to generate a eof character using format, say?
>
> There is no EOF character. EOF is not a character, it's a condition.
For files, that is generally true. But for sockets and interactive
streams, it is a problematic statement (not false, just problematic).
For such streams, EOF tends indeed to be sent via a character, usually
EOT (Control-D). The EOF is more closely assosiated with a character
than with a condition, because a second read on a socket that has just
read EOF will _not_ read the eof again.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@franz.com>, Duane Rettig <·····@franz.com>
wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > "remixer" <········@gmail.com> writes:
> >
> > > I am using Allegro. My lisp is talking to an interactive program using
> > > run-shell-command, and the interactive program expects an eof character
> > > to terminate my input to it. Is there a standard or a franz specific
> > > way to generate a eof character using format, say?
> >
> > There is no EOF character. EOF is not a character, it's a condition.
>
> For files, that is generally true. But for sockets and interactive
> streams, it is a problematic statement (not false, just problematic).
> For such streams, EOF tends indeed to be sent via a character, usually
> EOT (Control-D). The EOF is more closely assosiated with a character
> than with a condition, because a second read on a socket that has just
> read EOF will _not_ read the eof again.
This is only true for *terminals*, because there's no "end" to a
terminal connection (except perhaps for hanging up on a dialup modem,
although this is usually considered a more exceptional situation that
should be handled specially). The terminal driver translates a special
character into the EOF condition on the stream to emulate this. But the
character never appears in the stream -- it's more like the way
Control-C causes an interrupt.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Thanks. This makes sense. But in unix, doesnt Ctrl-D generate an EOF
condition?
[·······@stn] cat > foo.txt
type some random junk
Ctrl-D
[·······@stn]
My "interactive command" is like cat above, and it expects a Ctrl-D.
Probably my question was wrongly phrased. My question is, can I do the
above interaction from inside lisp, using something like
run-shell-command, that takes a string as input and executes it on the
shell.
Now, this is a very poor model of interaction, but I just wanted to do
this to try this out. At this point, I am looking at Franz's docs, but
havent figured this out yet.
"remixer" <········@gmail.com> writes:
> Thanks. This makes sense. But in unix, doesnt Ctrl-D generate an EOF
> condition?
This is different. The C-d character is handled by the terminal
driver, which translate it to an EOF condition the next time the
program tries to read from the terminal.
But in the case of run-shell-command, there's no terminal.
You could set up things with a pseudo terminal (pty) between your
program and the "interactive" inferior program. Or you could use
expect(1) to do the job.
It's just much simplier to close the stream.
> [·······@stn] cat > foo.txt
> type some random junk
> Ctrl-D
> [·······@stn]
>
> My "interactive command" is like cat above, and it expects a Ctrl-D.
No. It expects and End of File condition.
cat <<EOF >foot.txt
tralala
EOF
works too: the shell just closes the pipe when it reads EOF. No C-d
here, just E O F RET.
> Probably my question was wrongly phrased. My question is, can I do the
> above interaction from inside lisp, using something like
> run-shell-command, that takes a string as input and executes it on the
> shell.
C-d is a character like any other. The most probable is that you will
just be sending C-d to the other program and not closing anything:
#+clisp
(let ((cat (ext:run-program "cat" :arguments '("-A") :input :stream)))
(format cat "Hello~%")
(loop (format cat "~C" (code-char 4))))
Hello$
^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D ...
So don't be confounded by the keyboard user interface where it's nice
to have a key to signal the system you want to close the file or
terminal, and the real action which is always to close the file, the
terminal, the pipe, the socket, whatever.
In the case of pipes, it looks a little special, for if the pipe is
opened again after the close and data is written ("appended" actually)
_before_ the reader reached the first "end of file", then the reader
will not see the end of file at the first position, but at the later.
But this is actually completely coherent with the normal files, where
if data is appended, then the reader will not get the EOF condition at
the first position, but at the later.
There are some other strange devices where you can continue to read
after a End Of File condition. For example tapes. But:
1- the EOF is still not a character, it's a special modulation
recorded on the tape.
2- the End of Tape condition, EOT, is still not a character, but
generally two EOF special modulations.
That said, when I was a child I've been told this fairy tale: Once
upon a time, in a strange land near Seatle, there was a dark
corporation with bad witches up a dungeon who designed a system where
the file size was expressed in term of disk sectors. Then some
obscure servant programmers in the entrails of that castle got the
idea to mark the end of text files with a Control-Z character to
implement files of any size. -- Just a legend if you ask me...
--
__Pascal Bourguignon__ http://www.informatimago.com/