Re: [dev] [st][PATCH] Add support for utmp in st

From: <k0ga_AT_shike2.com>
Date: Sun, 12 Oct 2014 09:48:56 +0200

> On Sat, Oct 11, 2014, at 04:07, k0ga_AT_shike2.com wrote:
>> Value of erase key for example, or in general the configuration
>> of line kernel driver
>
> These can't come from the profile either; since st opens a new tty that
> is not the same device the user logged in on.

And the profile runs in the same tty that st opens. St by default
executes a non login shell, so profile is not loaded, but utmp executes
a login shell (because it creates the utmp session, so it is more
logical for it to execute a login shell). Other terminal emulators
have flags to enable or disable login shells, and even st in the
first versions always opened a login shell.

> (stty(1)). Backspace key in st generates
>> BACKSPACE, but almost all terminals generate DELETE instead
>> (read FAQ for more details).
>
> It's not clear why the position of the key and the intent of the user
> typing it is less important than the label of the key.

Did you read the FAQ?. What is the intention of the user?, what is
the meaning of DELETE, or the meaning of BACKSPACE?, what is the key
that erases the previous character?. The keyboard only generates
ASCII codes, and the interpretation of these codes must be done by
other program. Today, linux and BSD usually deals DELETE as key to
delete the previous character, but this is not true in all the
systems. I work with systems where BACKSPACE deletes the previous
character, and it is really painful you cannot generate a BACKSPACE
character with some terminal emulators. The position of St developers
is very clear about this topic, st must generates the correct ascii
value for each key.

> Their meaning is defined in the standard. The method of obtaining
> default values is not, but that means it's the implementation's
> responsibility, not that it doesn't mean anything at all.

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.

> But unsetting it, along with the initial call to cresize, should be fine
> on most systems, so maybe I've been too harsh about this.

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. It is
even worse, what environment should modify the terminal?, once that
shell is running the environment of it and environment of the terminal
are different, and then if the terminal updates COLUMNS or LINES the
shell will not see these updates.

The shell catches SIGWINCH and updates the variables. If you are
running a different program in this moment, then the variables will
not be affected. Once the shell becomes foreground process of the
terminal, then it updates the variables, that next child of the shell
will see updated.

Regards,
Received on Sun Oct 12 2014 - 09:48:56 CEST