headers
Brook Milligan | 1 Jun 2012 08:21

Re: programming with pty(4)

On Thu, 31 May 2012 21:45:47 +0000 (UTC)
christos <at> astron.com (Christos Zoulas) wrote:

> In article <20120531120352.4c293fba <at> viola.nmsu.edu>,
> Brook Milligan  <brook <at> nmsu.edu> wrote:
> >I have a program that opens a pty(4) on a NetBSD box and
> >reads/writes on the master side.  I can connect to the slave side
> >with tip(1) and communicate perfectly with the master side of the
> >pty(4).  However, if I disconnect tip(1) with ~^D and try to
> >reconnect, tip(1) reports a 'Device busy' error.  Presumably, I need
> >to detect the fact that tip(1) disconnected and do something to the
> >pty(4) device in order to allow a later connection, but I'm not sure
> >(i) how to detect the disconnection and (ii) what to do when it
> >happens.
> >
> >Any help with programming pty(4) devices is greatly appreciated.
> 
> Are you using BSD pty's or PTYFS?

BSD pty(4).

Cheers,
Brook
Permalink | Reply | 3 comments |
headers
Jörn Clausen | 1 Jun 2012 13:31

Re: Delete key no longer works after update to 6.0_BETA2

Thanks for the various suggestions and pointers.

On Fri, Jun 1, 2012 at 10:51 AM, Julian Coleman <jdc <at> coris.org.uk> wrote:
> This might be a side-affect of us pulling in later xterm definitions with
> the switch from termcap to terminfo.  If you set your terminal type to
> "xterm-old" or "xterm-r5" does that help?

When I set TERM to xterm-old, everything seems to be okay. Using
xterm-r5, the problem with inverted text is no longer present, but
another problem remains, I forgot to mention: When using the history
function of the shell, the cursor is not moved to the beginning of the
line, i.e. the command line grows longer and longer with entries from
the history.

--

-- 
Joern Clausen
http://thebloeg.blogspot.com/
http://www.oe-files.de/photography/
Permalink | Reply | 3 comments |
headers
Julian Coleman | 1 Jun 2012 13:58
Picon

Re: Delete key no longer works after update to 6.0_BETA2

Hi,

> When I set TERM to xterm-old, everything seems to be okay. Using
> xterm-r5, the problem with inverted text is no longer present, but
> another problem remains, I forgot to mention: When using the history
> function of the shell, the cursor is not moved to the beginning of the
> line, i.e. the command line grows longer and longer with entries from
> the history.

A summary here would be that different xterm implementations are incompatible.
Hence, there are different xterm-* entries in both termcap and terminfo.  Our
previous termcap "xterm" entry was a mixture of older and newer entries, but
lost some features of both.  I'm not sure that it's sensible to restore it
for our terminfo "xterm" entry though.

Thanks,

J

--

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/
Permalink | Reply | 2 comments |
headers
Christos Zoulas | 1 Jun 2012 14:28

Re: programming with pty(4)

On Jun 1, 12:21am, brook <at> nmsu.edu (Brook Milligan) wrote:
-- Subject: Re: programming with pty(4)

| On Thu, 31 May 2012 21:45:47 +0000 (UTC)
| christos <at> astron.com (Christos Zoulas) wrote:
| 
| > In article <20120531120352.4c293fba <at> viola.nmsu.edu>,
| > Brook Milligan  <brook <at> nmsu.edu> wrote:
| > >I have a program that opens a pty(4) on a NetBSD box and
| > >reads/writes on the master side.  I can connect to the slave side
| > >with tip(1) and communicate perfectly with the master side of the
| > >pty(4).  However, if I disconnect tip(1) with ~^D and try to
| > >reconnect, tip(1) reports a 'Device busy' error.  Presumably, I need
| > >to detect the fact that tip(1) disconnected and do something to the
| > >pty(4) device in order to allow a later connection, but I'm not sure
| > >(i) how to detect the disconnection and (ii) what to do when it
| > >happens.
| > >
| > >Any help with programming pty(4) devices is greatly appreciated.
| > 
| > Are you using BSD pty's or PTYFS?
| 
| BSD pty(4).

Make sure you close all the file descriptors, or use revoke(2) on the pty.

christos
Permalink | Reply | 2 comments |
headers
David Lord | 1 Jun 2012 16:07

Re: Delete key no longer works after update to 6.0_BETA2

On 1 Jun 2012 at 13:19, Julian Coleman wrote:

> Hi,
> 
> > I tried with vt220 changed to pcvt25 and that seems to 
> > have my delete key working.
> 
> I'm not sure that I understand the underlying problem here.  There are four
> things to consider:
> 
>   1) the key or sequence that is sent when the "delete" or "backspace" keys
>      are pressed
> 
>   2) the terminal erase character (stty erase, used for command-line erase)
> 
>   3) the termcap/terminfo entry (which describes the backspace and delete key
>      sequences (kb/kbs and kD/kdch1)
> 
>   4) how the application determines the delete key sequence (tty settings,
>      termcap/terminfo, etc.)
> 
> So, it would be nice to check all these.  It seems that 2) and 3) haven't
> changed (you mentioned stty erase ^?, and I looked at /usr/share/misc/termcap
> and /usr/share/misc/terminfo).  If you type:
> 
>   echo <ctrl-V><delete> | vis
> 
> what output do you see?  (<ctrl-V> is control-v, but control-6 for ksh)  I
> see:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julian Coleman | 1 Jun 2012 16:38
Picon

Re: Delete key no longer works after update to 6.0_BETA2

Hi,

> 'Delete' from numeric keypad tabs 1 character right
> rather than erase of character under cursor.

Oh - *that* delete key.

> $ echo ^[[3~ | vis    = same as NetBSD-5
> \^[[3~

Our old termcap entry for vt220 has "kD=\E[3~", but there is no "kdch1"
capability in the terminfo vt220 entry.  As wsvt25 inherits from vt220 in
both, we lost that delete key entry between 5 and 6.

Thanks,

J

--

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/
Permalink | Reply | 1 comment |
headers
Brook Milligan | 1 Jun 2012 17:05

Re: programming with pty(4)

Christos,

On Fri, 1 Jun 2012 08:28:49 -0400
Christos Zoulas <christos <at> zoulas.com> wrote:

> Make sure you close all the file descriptors, or use revoke(2) on the
> pty.

Thanks.  Perhaps I am misunderstanding revoke(2).  It sounds like that
is something I should be doing after I use openpty(3) so that the
initial connection will not be confused with any prior ones.  However,
my problem is not with the first connection; that works fine.  The
problem is after a connection is made with tip(1) and disconnected with
'~^D' then a subsequent connection fails (unless done by root).

If I am to do another revoke(2) call, when should I do that?  How will
I know that the first connection has been disconnected?  If I just
timeout after inactivity will the fact that the slave side of the
pty(4) disappears create problems for clients that were just inactive
but still connected?

Thanks for the help.

Cheers,
Brook
Permalink | Reply | 1 comment |
headers
Christos Zoulas | 1 Jun 2012 18:18

Re: programming with pty(4)

On Jun 1,  9:05am, brook <at> nmsu.edu (Brook Milligan) wrote:
-- Subject: Re: programming with pty(4)

| Christos,
| 
| On Fri, 1 Jun 2012 08:28:49 -0400
| Christos Zoulas <christos <at> zoulas.com> wrote:
| 
| > Make sure you close all the file descriptors, or use revoke(2) on the
| > pty.
| 
| Thanks.  Perhaps I am misunderstanding revoke(2).  It sounds like that
| is something I should be doing after I use openpty(3) so that the
| initial connection will not be confused with any prior ones.  However,
| my problem is not with the first connection; that works fine.  The
| problem is after a connection is made with tip(1) and disconnected with
| '~^D' then a subsequent connection fails (unless done by root).

On the server process side you need to detect that the slave closed, and
close the master. If you revoke(2) after you openpty(3) you are not going
to be able to use the pty. revoke(2) was designed pre-openpty, and it was
meant to be called after scanning the list of pty's and before opening it.

| If I am to do another revoke(2) call, when should I do that?  How will
| I know that the first connection has been disconnected?  If I just
| timeout after inactivity will the fact that the slave side of the
| pty(4) disappears create problems for clients that were just inactive
| but still connected?

If you use ptyfs, then you can check in /dev/pts that the pty is closed
(Continue reading)

Permalink | Reply | 0 comments |
headers
James K. Lowden | 1 Jun 2012 19:10
Gravatar

where is netbsd-INSTALL.gz?

[I'm posting this to the docs list because it's an issue either of
release engineering or documentation, and there's no releng <at> , and
because no one answered at netbsd-users.]

netbsd-INSTALL.gz does not exist on ftp.NetBSD.org
at /pub/NetBSD/NetBSD-5.1.2/i386/binary/kernel/.  The documentation
says it should be there, and there's no README or errata file indicating
if it's been removed or why.  

ftp> nlist *IN*
netbsd-INSTALL_FLOPPY.gz
netbsd-INSTALL_FLOPPY.symbols.gz
netbsd-INSTALL_XEN2_DOMU.gz
netbsd-INSTALL_XEN3PAE_DOMU.gz
netbsd-INSTALL_XEN3_DOMU.gz

A link to the document I'm reading: 

http://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.1.2/i386/INSTALL.html#NetBSD/i386%20subdirectory%20structure

Here's an interesting list:

ftp> nlist /pub/NetBSD/NetBSD*/i386/binary/kernel/netbsd-INSTALL.gz
/pub/NetBSD/NetBSD-4.0.1/i386/binary/kernel/netbsd-INSTALL.gz
/pub/NetBSD/NetBSD-4.0/i386/binary/kernel/netbsd-INSTALL.gz
/pub/NetBSD/NetBSD-6.0_BETA/i386/binary/kernel/netbsd-INSTALL.gz
/pub/NetBSD/NetBSD-6.0_BETA2/i386/binary/kernel/netbsd-INSTALL.gz

It would appear the install kernel went missing for a while and has
reappeared.  I don't know if that was intentional or went unnoticed,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Husemann | 1 Jun 2012 21:32
Picon

Re: where is netbsd-INSTALL.gz?

On Fri, Jun 01, 2012 at 01:10:02PM -0400, James K. Lowden wrote:
> It would appear the install kernel went missing for a while and has
> reappeared.  I don't know if that was intentional or went unnoticed,
> but it's definitely undocumented.  

From the commit log that fixed it:

---8<---
revision 1.65
date: 2011/02/10 00:43:20;  author: jym;  state: Exp;  lines: +3 -2
Reinstate INSTALL kernel for embedded ramdisk installs.

Reasons being:
- INSTALL is GENERIC with an embedded ramdisk, and as such, can benefit from
features included within.
- INSTALL_FLOPPY has its own config(5) file, and is tailored for "small"
floppy images; it misses features/drivers that could be needed to boot
in a decent environment for recent x86 machines (like ACPI)
- makes it closer to floppies distrib available for amd64

While here, comment out INSTALL_FLOPPY and bootfloppy-big image build. NetBSD
does not use the 3.6MiB image for El Torito cdroms anymore.

Remove the FLOPPYMAX limit; i386 needs 4 floppies now. Modify boot.cfg and
release/contents to reflect reality.

See http://mail-index.netbsd.org/port-i386/2011/02/08/msg002307.html

No comments, no objections.
--->8---
(Continue reading)

Permalink | Reply | 0 comments |

Gmane