Cygwin, zpty and EOL

Cygwin, zpty and EOL

[Andrej Borsenkow]

Trying to make nslookup work on Cygwin ...

Cygwin can work with tty in two different modes. In binary mode all
characters are transmitted "as is", that corresponds to normal Unix
behaviour. In text mode EOL is converted between NL (Unix) and CR-NL
(DOS). Important is, as I understand, it is done by cygwin.dll, and
applies only to Cygwin programs.

Unfortunately, nslookup on NT is external, NT program. When you start it
under zpty control, very funny thing happens:

- by default, terminal is set to "stty onlcr" mode (BTW the same is on
Unix and with Bash).

- nslookup, as DOS program, outputs CR-NL as EOL

- this is converted to CR-CR by pty (that interprets it as output, of
course)!

In other words, poor nslookup that waits for '*NL> ' never sees it ...
and what it gets is one large large line.

I was finally able to make it work by changing the pattern and replacing
CR-CR with single NL in input. Ough ...

This probably could be automated by examining full path to the command.
Now I wonder, if something similar happens with completion tests. So far
I noted very interesting thing - every ptyread() returns single line, at
the end of line I see read() that returns 0 (zero) bytes.

-andrej

Have a nice DOS!
B >>

Re: Cygwin, zpty and EOL

[Bart Schaefer]

On Jul 6,  7:21pm, Andrej Borsenkow wrote:
} Subject: Cygwin, zpty and EOL
}
} I noted very interesting thing - every ptyread() returns single line, at
} the end of line I see read() that returns 0 (zero) bytes.

That's because it's using a non-blocking read.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Cygwin, zpty and EOL

[Andrej Borsenkow]

> On Jul 6,  7:21pm, Andrej Borsenkow wrote:
> } Subject: Cygwin, zpty and EOL
> }
> } I noted very interesting thing - every ptyread() returns
> single line, at
> } the end of line I see read() that returns 0 (zero) bytes.
>
> That's because it's using a non-blocking read.
>

Huh? May be I was not clear - it happened only on *Cygwin*. The same
output on Unix is read in full. So, if it relates to non-blocking read,
then Cygwin behaves very strange is this respect.

Eh, and can you explain, how non-blocking read relates to EOF after
every line? If terminal is in non-blocking mode, and no data is
available, read() returns -1 and sets errno to EWOULDBLOCK or EAGAIN
(that are the same here).

Consider:

Unix:

bor@itsrm2% zmodload zsh/zpty
bor@itsrm2% zpty ls ls
bor@itsrm2% zpty -r ls
Brodsky      addrbook.d   dikz         observe      test
FM2000       bin          fnt          save         tmp
ICONS        dead.letter  mail         src          xxxx

Cygwin (to work around EOL problem):

mw1g017@MW1G17C:~% zmodload zsh/zpty
mw1g017@MW1G17C:~% zpty ls ls
mw1g017@MW1G17C:~% zpty -r ls foo
mw1g017@MW1G17C:~% print ${foo//$'\C-M\C-M'/$'\C-J'}
GIZ              Outlook Express  autoname.dat     q.log
mw1g017@MW1G17C:~% ls
GIZ              Outlook Express  autoname.dat     q.log
MAD_COW.doc      Palm             foo              serial.txt
MAD_COW.zip      Pilot            foo1             sm.dat
My Documents     Win2k            gdbtk.ini        src
Old old old      _viminfo         profile-NT4      test

-andrej