🚀 go-pugleaf

> I think there should be three parts of stty :
> 	o pretty  - a curses based terminal setter
> 	o gstty   - the actual program (reformed and much better command set)
> 	o xpretty - a x-based front end to gstty similar in style to pretty, but
> 		    with x-widgets to select various settings for example.

Keep in mind that POSIX.2 specifies a standard stty program, which GNU
will continue to support for POSIX and Unix compatibility.  It looks
from what you wrote as if you are unaware that GNU is already
distributing a (POSIX compliant) stty program; it is part of the
shellutils package.

If you are going to invent a new interface, make it a new program and
give it a completely new name.  Something like setupterm, or
termconfig, perhaps.  Do *not* call it gstty.  gawk and gcc are only
temporary names while those programs are running under Unix, to avoid
confusing them with the Unix versions.  On GNU systems, they will be
called awk and cc.

I also do not think the names pretty and xpretty describe those
programs' function well.

The arguments to the POSIX stty are an almost direct mapping to the
POSIX termios C interface.  If you are going to invent a new syntax
for configuring terminals, I suggest you write it as a library layered
on top of termios.  Then write pretty, xpretty, and the noninteractive
command line program all using that library, instead of execing a
program in pretty and xpretty.  Or just write pretty and xpretty using
termios directly; there is no great need for them to deal with the
terminal in any other way.  Alternately, instead of a curses based
program, you might consider an emacs-lisp package.

> gstty -set [variable[=value[,value]]|all|everything|help|?]
>       -mode [[-]mode|help|?]
>       -enable [[-]signal|help|?]
>       -term [terminal|help|?]
>       -map [key[=binding[,binding]]|help|?|all|everything|default]
>       -sane
>       -reset
>       -interactive
>       -help [command|variable]
>       -?

For parsing command line options to a new program, use the GNU
getopt_long function.  This means that long-named options will start
with a `+' instead of `-'.

I don't think programs, particularly command line utilities, should
have extensive help strings compiled into them.  That's what the Info
system is for.  So I am wary of "help" options.  It makes the binaries
bloat and is hard to change and browse.  (I do not like bash's builtin help.)

> And have a global /usr/local/etc/sttyrc or similar file which can provide
> aliases like :

> alias disable 'enable -$*'		# saves code! :-)
> alias isig 'set sig=on'			# emulate the old command set! 
> alias default ... 			# and so on and on...

I don't see a need for that.  I think it is overcomplicated.  Just
design the command set well from the start and you won't need aliases.

> The idea being that if the user uses the old command set, they can, and
> saves stty from being a HUGE application, but this incurs a penalty for
> the using old command set as the old set and any aliases are only read
> in after stty has failed in its command parsing.

Don't encumber the stty program with all the new stuff; make a new program.
The name stty isn't great, anyway (who uses TTYs anymore?).

> 	The command 'set' is used to set all sorts of variables and
> 	settings so that it reduces huge numbers of commands down to a
> 	smaller, more manageable number. This makes stty faster and
> 	smaller... 

I question that last statement.  I don't see any reason why it would
be true.  All the set command does is add another layer of parsing.

All you seem to have done is replace "stty -parity" with
"stty -set parity=off".  I don't see how that is an improvement.
Perhaps a new command line utility is not needed at all; you don't
seem to have come up with any real improvements over stty so far.

> gstty -term vt100

> and stty is correctly setup for a vt100 as default ready for sh, etc to
> take over.

Have you looked at the tset command?  It does something similar to this.
What sorts of things can you deduce from the terminal type?  The
backspace character perhaps.  What else?

> 	I am going to use the standard key binding names from curses (see
> curses(3x) for more info, near the back...) to specify the action taken by
> the key so you can bind more than just the carriage return action... But
> for starters, the standard CR CRNL bindings will be enough. I will add
> actions as time goes on...

Binding for what -- the terminal driver, or the pretty command?
Are you proposing to write a new line discipline?  I do not understand
this paragraph.  

> 	Loads up pretty (or xpretty if term is set to xterm) and allows the

This is a useless option.  If the user wants to run pretty, it is
easier to type "pretty" than to type "stty -interactive".

> user with no or little familiarity with gstty or stty to set modes quickly
> and get correct terminal definitions. The pretty program should reset the 
> mode of the terminal + changes when it leaves... So that a calling program
> like nn or elm doesn't get upset about being in cbreak mode or similar.

If the user's terminal is set up wrong, it will do no good to run a
curses-based program, which will probably not display properly!  That
is why stty is a non-interactive command.

> 	Help is available on all commands and there is a help mode which
> basically is a clever interactive manual page... Similar to emacs'
> help mode (^H-key). 

It is a good idea for the curses and X based programs to have this.

I think you need to re-evaluate the purpose of the interactive
programs.  They are not useful for getting the terminal you are
currently using to work properly (the X program won't even have a tty
associated with it).  You can only use them when you are on a terminal
that is already working properly, or very close to it.  You could use
them to manage, in an easily understood way with lots of descriptive
help texts and suggested combinations of settings for typical situations,
a database that relates terminal type, and perhaps baud rate and tty
(like the tset -m option), to personal customized settings.  You could
also have global settings that apply to all terminal types.  Then in
your .cshrc or .bashrc you would run a program that reads the TERM
environment variable, looks in the database, and sets up the tty
appropriately.
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>