zpty

zpty

[Oliver Kiddle]

Even using a working zpty on Linux/Solaris, it seems it has issues.
(I've never really used zpty before.)

The first thing which is easy to fix is that the completion function
was missing a couple of options. A patch for this is attached.

Anyway, try running this:
  zpty test cat
  zpty -L
  ^C

Why does zpty -L need to call checkptycmd()? Is that to see if the
process is still alive? It tries to read one character which blocks.
Also, someone might care that it loses  $'\xff' characters. To be fair,
there's a comment above saying "a better process handling would be
nice". But can it be improved by using read_poll from utils.c?

That could perhaps also allow the -t option to take a timeout parameter
like read now does. However, rather than duplicating the whole of read,
the ideal would be if zpty would work more like coproc and we could
just use read, print, jobs etc to handle the commands.

Also note that you can only ever read from this cat zpty command by
hitting Ctrl-C.

Oliver

Index: Completion/Zsh/Command/_zpty
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Command/_zpty,v
retrieving revision 1.1
diff -u -r1.1 _zpty
--- Completion/Zsh/Command/_zpty	2 Apr 2001 11:33:55 -0000	1.1
+++ Completion/Zsh/Command/_zpty	17 Mar 2004 12:42:52 -0000
@@ -5,26 +5,30 @@
 
 
 _arguments -C -s -S \
-  '(-r -w -L -d)-e[echo input characters]' \
-  '(-r -w -L -d)-b[io to pseudo-terminal blocking]' \
-  '(-r -w -L -e -b)-d[delete command]:*:name:->name' \
-  '(-r -L -e -b -d)-w[send string to command]:name:->name:*:strings to write' \
-  '(: -r -w -e -b -d)-L[list defined commands as calls]' \
-  '(: -w -L -e -b -d)-r[read string from command]:name:->name:param: _vars:pattern:' \
-  '(-r -w -L -d):zpty command name:' \
-  '(-r -w -L -d):cmd: _command_names -e' \
-  '(-r -w -L -d)*::args:_precommand' && return 0
+  '(-r -w -t -n -L -d)-e[echo input characters]' \
+  '(-r -w -t -n -L -d)-b[io to pseudo-terminal blocking]' \
+  '(-r -w -t -n -L -e -b)-d[delete command]:*:name:->name' \
+  '(-r -L -t -e -b -d)-w[send string to command]:name:->name:*:strings to write' \
+  '(-r -L -t -e -b -d)-n[do not add a newline to the result]' \
+  '(: -r -w -t -n -e -b -d)-L[list defined commands as calls]' \
+  '(: -w -n -L -e -b -d)-r[read string from command]:name:->name:param: _vars:pattern:' \
+  '(: -w -n -L -e -b -d)-t[test if output is available before reading]' \
+  '(-r -w -t -n -L -d):zpty command name:' \
+  '(-r -w -t -n -L -d):cmd: _command_names -e' \
+  '(-r -w -t -n -L -d)*::args:_precommand' && return 0
 
 # One could use sets, but that's more expensive and zpty is simple enough.
 #
 # _arguments -C -s -S \
 #   - read \
 #     '-r[read string from command]' \
+#     '-t[test if output is available first]' \
 #     ':name:->name' \
 #     ':param: _vars' \
 #     ':pattern:' \
 #   - write \
 #     '-w[send string to command]' \
+#     '-n[do not add a newline to the result]' \
 #     ':name:->name' \
 #     '*:strings to write' \
 #   - list \

Re: zpty

[Peter Stephenson]

Oliver Kiddle wrote:
> Anyway, try running this:
>   zpty test cat
>   zpty -L
>   ^C
> 
> Why does zpty -L need to call checkptycmd()? Is that to see if the
> process is still alive? It tries to read one character which blocks.

Yes, I imagine so.  This is useless.  It needs to use non-blocking I/O,
otherwise it shouldn't even bother with the test --- hanging up is not
acceptable, even if the information returned is a little out of date.
So I think removing checkptycmd() for now ought to be an improvement
(haven't actually tried).

read_poll() would be an improvement, but care is needed --- the device
is a terminal and while there is some handling for that (i) it was
tricky and I nearly blew a gasket getting it to work on the systems I
tried, so we may be back in system-specific land (ii) currently it
assumes the terminal in use is the shell terminal, which isn't the case
here.  (In particulay, using select() and poll() on terminals didn't
always seemed to work, I had to use termios.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: zpty

[Peter Stephenson]

Alexey Tourbin wrote:
> I'm new to this mailing list.  I've been using zsh for a while.
> Recently I found out that zpty actually does not work on my Linux
> system.

[This is about the internals and should really go to zsh-workers rather
than zsh-users, so I've redirected this follow up.]

> As I digged into the code, I saw those old-style /dev/ptyxx heuristics
> which may not work on some modern Linux systems because the location is
> changed to /dev/pts/xx.  Meanwhile there's an API in glibc for dealing
> with pseudo terminals.  So I reworked that code a bit.
> 
> Now it works fine for me.  Of course it's not portable, it works with
> glibc only.  But glibc is one of the most popular libc implementation,
> and it works not on Linux systems only.  So please consider whether this
> can be useful somehow.

This is very useful, thank you, but as with the NIS/NIS+ patch I just
commented on, it can't go in without some configuration test.  It looks
like testing for getpt, grantpt and unlockpt functions in zshconfig.ac
might do the trick (I see it also does some streams handling, which is
kernel-specific and we can't really assume, either), so we might be able
to do it; however, it won't happen straight away.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

RE: zpty

[Borzenkov Andrey]

> 
> I'm new to this mailing list.  I've been using zsh for a while.
> Recently I found out that zpty actually does not work on my Linux
> system.
> 
> $ zmodload zsh/zpty
> $ zpty date date
> zpty: can't open pseudo terminal: bad file descriptor
> $
> 
> As I digged into the code, I saw those old-style /dev/ptyxx heuristics
> which may not work on some modern Linux systems because the location is
> changed to /dev/pts/xx.  Meanwhile there's an API in glibc for dealing
> with pseudo terminals.  So I reworked that code a bit.
> 

the location has not changed. /dev/pts are for SVR4 ptys; it depends on your
system if they are compiled in kernel (as well as old-style ones).

> Now it works fine for me.  Of course it's not portable, it works with
> glibc only.  But glibc is one of the most popular libc implementation,
> and it works not on Linux systems only.  So please consider whether this
> can be useful somehow.
> 

This won't without suitable configure tests. You can't assume glibc is the
only existing libc implementation. Your patch simply kills zpty on my
system. If you change your patch to probe for SVR4-style ptys on Linux in
addition to traditional ones without touching other systems, I's say it may
be included.

The same applies to headers, you can't include headers without testing for
their existence. error.h does not exist here.

BTW convention is that all includes and in <module>.h not in C files, but it
may be not as strict.

-andrey