4

We would like to run some curses based apps in background.

These apps use curses and get the current tty port name to be used internally to map log files and others context-terminal associations.

In some tests just redirecting the input from curses apps that don't read the keyboard to a known pts, worked. And so they can be executed in background, since I reserve a tty (or pseudo tty) for that.

Is it possible to mock a tty, or has a reserved pts to some automatic running purposes, like that? We plain to launch them through crontab.

ctrl-alt-delor
  • 27,473
  • 9
  • 58
  • 102
Luciano
  • 1,129
  • 4
  • 15
  • 26
  • 1
    There are programs for this *(`socat`, `screen`, etc.)*, but maybe see [How did I come by this pty and what can I do with it?](http://unix.stackexchange.com/q/179030/52934). Two of my favorites among those programs are `luit` *(it comes w/ `xterm`)* and the heriloom toolchest's [`shl`](http://heirloom.sourceforge.net/man/shl.1.html). – mikeserv Jul 08 '15 at 21:21

1 Answers1

2

A history of toolsets

The earliest tool for this sort of thing was Daniel J. Bernstein's "pty" package, described by Rich Salz as a "Ginsu knife", which he wrote back at the turn of the 1990s in order to cheat at nethack (sic!). Version 4 of the "pty" package was published in 1992 to comp.sources.unix (volume 25 issues 127 to 135). It's still locatable on the World Wide Web. Paul Vixie described it at the time:

What can I say? It slices, it dices, it washes dishes, it walks the dog. It "just works", meaning that if you follow the directions you'll get a working package without any pulling of hair or gnashing of teeth or other standard porting activities.

Bernstein later updated this, somewhen on or before 1999-04-07, with a "ptyget" package, which he announced:

I've put together a new pseudo-tty allocator, ptyget. An alpha version is at ftp://koobera.math.uic.edu/pub/software/ptyget-0.50.tar.gz. There's a ptyget mailing list; to join, send an empty message to [email protected]. I designed ptyget's interface from scratch. It's much more modular than pty; the basic pty interface has now been split into three pieces:

  • ptyget: a tiny, low-level program — the only setuid program in the package — that allocates a new pseudo-tty and passes it to the program of your choice
  • ptyspawn: another small program that runs a child process under a pseudo-tty, waiting for it to exit and watching for stops
  • ptyio: another, only slightly larger, program that moves data back and forth

The old Ginsu knife pty is now spelled ptybandage, which is a synonym for ptyget ptyio -t ptyspawn; pty -d, for attaching network programs to pseudo-ttys, is now spelled ptyrun, which is a synonym for ptyget ptyio ptyspawn; and nobuf is a synonym for ptyget ptyio -r ptyspawn -23x. I've split off the session management features into a separate package.

That separate package was the "sess" package.

"ptyget" is, incidentally, notable for exemplifying a very early version of, and one of the few published instances of, Berstein's own never-published "redo" build system. dependon is a clear precursor to redo-ifchange.

Available toolsets

Dru Nelson publishes both "pty" version 4 and "ptyget".

Paul Jarc publishes a fixed version of ptyget, that attempts to deal with the operating-system-specific pseudo-terminal device ioctls in the original that operating systems actually no longer provide.

The nosh source package comes with workalike ptybandange and ptyrun scripts, which use Laurent Bercot's execline tool and the nosh package's own pseudo-terminal management commands.

A few example uses

Jurjgen Oskam using ptybandage on AIX to feed input from a here document to a program that explicity opens and read its controlling terminal for a password prompt:

$ ptybandage dsmadmc <<EOF >uit.txt
joskam
password
query session
query process
quit
EOF

Andy Bradford using ptyrun on OpenBSD under daemontools and ucspi-tcp to make the bgplgsh interactive router control program accessible via the network whilst making it think that it is talking to a terminal:

#!/bin/sh
exec 2>&1
exec envuidgid rviews tcpserver -vDRHl0 0 23 ptyrun /usr/bin/bgplgsh

Further reading

JdeBP
  • 66,967
  • 12
  • 159
  • 343
  • I don't think djb's `pty` outdated `shl` - which kind of outdated ptys in the first place as far as I know and came with SVR3 - it used a special `stty loblk` setting and `stty SWTCH` char/sig pair. And GNU [`screen` was initially released in 87](https://en.m.wikipedia.org/wiki/GNU_Screen), anyway. – mikeserv Jul 10 '15 at 10:49
  • Shell layers were System 5's answer to BSD job control, and aren't what the questioner is asking for. Neither is `screen`, whose release year I am well aware of thank you, since I was one of the earliest people to compile, play with, and (alas, only privately) alter it. The earliest tool for what the questioner is asking about is `pty`. – JdeBP Jul 10 '15 at 11:01
  • Do you mean to say that the asker could not today background a process wrapped in a pseudo-terminal w/ `screen` - or that it was not possible in '87? I might believe the latter - because I don't know better - but the former won't fly - I know you can do that today. – mikeserv Jul 10 '15 at 11:09
  • Nope, won't buy the '87 thing either - not [now that I know better](https://groups.google.com/forum/m/#!topic/net.sources/5V9QWdIynTY). Even in '87 you could have used it to meet the asker's needs. Here's the head of a function from the '87 source: *`static OpenPTY () { register char *p, *l, *d; register i, f, tf; strcpy (PtyName, PtyProto); strcpy (TtyName, TtyProto); for (p = PtyName, i = 0; *p != 'X'; ++p, ++i) ;...`* – mikeserv Jul 10 '15 at 11:19
  • 1
    You still aren't reading what the questioner is asking for. You're answering _some other question_, not actually asked. The questioner wants a toolset for "mocking a PTY", running things that expect TTYs from cron, and manipulating PTYs with shell commands. Thinking that `screen` is the right tool leads one to foolishness like the scripts at http://unix.stackexchange.com/questions/212059/ . Not everything is a nail, and `screen` is not your hammer. – JdeBP Jul 10 '15 at 11:33
  • No, I didn't answer any question - you did. It's a pretty good answer, too, but you have apparently placed some opinions of your own ahead of the facts in this case. And you definitely could manipulate ptys w/ *screen* commands in '87. As I see what is asked for is a reserved pty - even one which a script launched from cron might just print at via redirection - and the '87 `screen` could have easily provided that - or 10 of those. Now I never use `screen` - and don't care to learn how - but it definitely predated `pty` - which I do use and quite like *(`ptyget`, anyway)*. It's not my hammer. – mikeserv Jul 10 '15 at 11:44
  • No, you have placed your words into my mouth and constructed straw men about `screen` and then claimed them to be counterfactual and my opinions. I have simply reiterated three times the point made in the first six words of the first sentence of the answer, namely the earliest tool for this job. Not the earliest tool that made _any_ use of PTYs. Not whether some other tools that do different jobs were earlier.The earliest tool for this job at hand. It's still [the same answer as people were giving 20 years ago](https://groups.google.com/d/msg/comp.unix.aix/lu_codRI2_Y/Mfrj4nQ72AQJ). – JdeBP Jul 10 '15 at 12:23
  • ok. I was really hoping to upvote this answer, too. It is pretty good - I really like the you way you cite all that stuff in these things - just as you did w/ FGA. But it is factually incorrect. The fact is that, while a modular tool like `pty` should be preferred to a bulky session manager like `screen`, both *could* satisfy in a pinch, and one came earlier. I'm sorry we don't agree, but you draw a hard line which I see past. And your link cites a *few* programs, but names only `pty`, which, while handy, [is not needed on a modern Linux, anyway](http://unix.stackexchange.com/q/179030/52934). – mikeserv Jul 10 '15 at 12:37