Hi all,
It is my current understanding that CON on Windows is the bidirectional
equivalent of stdin and stdout in Unix. I'm hoping for tips as to why CON
disappears when trying to open it for output instead of input. Here's GCL
(I'm using the binary downloaded from
<http://ftp.gnu.org/gnu/gcl/binaries/stable/gcl_2.6.6.mingw32_ansi_japi_20050210.exe>
Note that I had to manually perform a file delete and rename that didn't
work in one of the installation scripts. If it happens to you you'll see
the error output before you press any key as part of the installation
process):
GCL (GNU Common Lisp) 2.6.6 ANSI Feb 10 2005 08:58:39
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
>(defparameter *stdin* (open "CON" :direction :input :element-type
'(unsigned-byte 8)))
*STDIN*
>*stdin*
#<input stream "CON">
>(loop (print (read-byte *stdin*)))
abc
97
98
99
13
10
Thus input appears to be working perfectly. But look at this:
>(defparameter *stdout* (open "CON" :direction :output :if-exists
:overwrite :element-type '(unsigned-byte 8)))
Error in SETQ [or a callee]: Cannot open the file CON.
Fast links are on: do (use-fast-links nil) for debugging
Broken at CONDITIONS::CLCS-OPEN. Type :H for Help.
1 (Continue) Retry opening file "CON".
2 (Abort) Return to top level.
dbl:>>
CLISP also tells me:
*** - Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the
file specified.
This is odd as CLISP can find "the file" when "CON" is specified as
an input file:
[4]> (open "CON" :element-type '(unsigned-byte 8))
#<INPUT UNBUFFERED FILE-STREAM (UNSIGNED-BYTE 8) #P"CON">
Thanks for your help.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> It is my current understanding that CON on Windows is the bidirectional
> equivalent of stdin and stdout in Unix. I'm hoping for tips as to why CON
> disappears when trying to open it for output instead of input.
My understanding was (at the time of MS-DOS) that CON: was equivalent
to /dev/tty, not to stdin or stdout. Check the difference with a
program writting to CON: launched with:
C:\> pgm_writting_to_con < input > output
>>(defparameter *stdout* (open "CON" :direction :output :if-exists
> :overwrite :element-type '(unsigned-byte 8)))
>
> Error in SETQ [or a callee]: Cannot open the file CON.
But why do you want to open it? You have the streams
*standard-input*, *standard-output* and *terminal-io* already open
for you.
(defparameter *stdout* common-lisp:*standard-output*)
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
From: Kalle Olavi Niemitalo
Subject: Re: Common Lisp and the Windows equivalent of stdin/stdout?
Date:
Message-ID: <87vf5yru46.fsf@Astalo.kon.iki.fi>
Pascal Bourguignon <···@informatimago.com> writes:
> My understanding was (at the time of MS-DOS) that CON: was equivalent
> to /dev/tty, not to stdin or stdout.
BTW, Windows has special CONIN$ and CONOUT$ file names as well.
http://msdn.microsoft.com/library/en-us/dllproc/base/console_handles.asp
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> My understanding was (at the time of MS-DOS) that CON: was equivalent
>> to /dev/tty, not to stdin or stdout.
>
> BTW, Windows has special CONIN$ and CONOUT$ file names as well.
> http://msdn.microsoft.com/library/en-us/dllproc/base/console_handles.asp
Which works with clisp 2.33 on win32, thanks.
With clisp 2.33.1 on cygwin, it doesn't work (it gives a UNIX error 21
(EISDIR)), and neither does "/dev/stdout" (there's no /dev/ on
cygwin).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
On Thu, 05 May 2005 10:48:25 +0300, Kalle Olavi Niemitalo wrote:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> My understanding was (at the time of MS-DOS) that CON: was equivalent
>> to /dev/tty, not to stdin or stdout.
>
> BTW, Windows has special CONIN$ and CONOUT$ file names as well.
> http://msdn.microsoft.com/library/en-us/dllproc/base/console_handles.asp
This may be usable for my purposes, thanks. In CLISP and GCL I can write
bytes to CONOUT$ and view them using FORCE-OUTPUT (if necessary). Here's
an example using CLISP 2.33.1 on Windows ME:
[1]> (defparameter *conout* (open "CONOUT$" :direction :output :element-type
'(unsigned-byte 8)))
*CONOUT*
[2]> (write-sequence #(97 98 99 13 10) *conout*)
abc
#(97 98 99 13 10)
[3]>
I realise the above will probably produce garbage upon a Unicode Windows
terminal since I did not output a UTF-16 encoded sequence. I will be able
to do so if I find a reliable way to detect the encoding. (getenv) in
CLISP returns, among other things, ("LANG" . "").
Regards,
Adam
On Thu, 05 May 2005 06:25:10 +0200, Pascal Bourguignon wrote:
> Adam Warner <······@consulting.net.nz> writes:
>> It is my current understanding that CON on Windows is the bidirectional
>> equivalent of stdin and stdout in Unix. I'm hoping for tips as to why CON
>> disappears when trying to open it for output instead of input.
>
> My understanding was (at the time of MS-DOS) that CON: was equivalent
> to /dev/tty, not to stdin or stdout.
Thanks. That makes more sense.
>>>(defparameter *stdout* (open "CON" :direction :output :if-exists
>> :overwrite :element-type '(unsigned-byte 8)))
>>
>> Error in SETQ [or a callee]: Cannot open the file CON.
>
> But why do you want to open it? You have the streams
> *standard-input*, *standard-output* and *terminal-io* already open
> for you.
>
> (defparameter *stdout* common-lisp:*standard-output*)
You may have recently noticed I've been interested in reading and writing
bytes to and from input and output streams :-) I just want to know if
the same approach that works upon Unix (opening /dev/stdin and /dev/stdout
as binary files) can be applied to Windows.
Many Common Lisp implementations prohibit the operation of READ-BYTE
and/or WRITE-BYTE upon *standard-input*, *standard-output* and *terminal-io*.
Regards,
Adam