> Why shouldn't a non-login shell have a utmp session? And if this option
> is to use a login shell, rather than merely using utmp, then I don't
> think it should be a compile-time option - just because someone
> sometimes wants a login shell (which could be done before, if desired,
> by running e.g. sh -l) doesn't mean they always want one.
St does not executes a login shell and not creates a utmp session. If you
want them, you have to use utmp that executes a login shell with utmp
session. At this point user has two options:
- Set utmp value: All terminals will create login shells and utmp
sessions. If he wants no login shell and no utmp session then he
can use 'st -e sh'.
- Unset utmp value: All terminals will create non login shell
without utmp sessions. If he wants login shell and utmp sesseion
then he can use 'st -e utmp'
You can see there is no necessity of new command line option.
I sent a patch long time ago that inserted utmp into st, but after
some discussion we thought was better to have a different application
which updates the utmp session of current tty.
> What character does DEL generate? I'm assuming it generates either
> DELETE or "Remove Here", and either way it's going to be equally painful
> that you can't generate one of the sequences that a VT220 does.
> Meanwhile, the VT220 has no key that generates Backspace.
I have a VT520 here that generates BACKSPACE. VT100 generated DELETE,
because it had a Delete key, but another versions of vt-xxx terminals
had a Backspace key. St is almost compatible with Vt100, with some
sequences of Vt220 and with some sequences ot Vt3xx, and some
sequences that were nver implemented by any vt-xxx terminal. It does
not mean we want a perfectly vt100 terminal emulator, because in that
case we would like to export TERM=vt100 instead of TERM=st-256color.
You can find terminal emulators that generate DELETE for PC Backspace
key and emulators that generate BACKSPACE for it. Old versions of xterm
generate BACKSPACE.
If the user doesn't like the key assignation on st he is free of changing it
in his config.h (maybe we could add it to the FAQ).
> You didn't comment on the prior/next/find/select issue, either.
I don't unerstand what you mean here.
>> Can you put here in which part of POSIX they are defined?. I'm
>> sorry, but they are not standard (although are commons), and
>> even there are some shells (dash for example) that don't set them.
>
> http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html
Quoting from this page:
It is unwise to conflict with certain variables that are
frequently exported by widely used command interpreters and
applications:
It doesn't specify that COLUMNS and LINES must be set, only that these
names are usually used and must be avoided. I already have explained
why the emulator cannot set the variables, but I am going to put another
example: Terminal emulator running in host A that creates a session in
host B, if the terminal emulator is resized how can it change variables
in B environments?. This is the reason any terminal emulator set them.
Do you think St should set them? (maybe we are saying the same, because
in other case I don't understand this conversation).
>> I'm sorry, but this is a work of the shell, because it is not possible
>> for a terminal (a real one, not emulated) to set variables.
>
> A real terminal has a fixed size, which is known in termcap/terminfo. If
> a terminal supports multiple sizes, you would historically have had to
> alter the variables manually.
Because they don't generate SIGWINCH, that it is a signal that only can
be generated by emulators.
If you run a shell with LINES and COLUMNS support they will be updated
without problems, so I don't know what you want.
Received on Sun Oct 12 2014 - 20:32:54 CEST