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

From: <k0ga_AT_shike2.com>
Date: Mon, 13 Oct 2014 20:38:27 +0200

> On Sun, Oct 12, 2014, at 14:32, k0ga_AT_shike2.com wrote:
> That doesn't mean that the question of what the default should be is not
> worth discussing.

Default configuration was discussed here some time ago, and suckless
developers agreed with current configuration. Both options, Backspace
generates BACKSPACE and Backspace generates DELETE have advantages and
problems, and usually emulators have some way of changing between them.
Xterm uses 3 resources for it: backarrowKeyIsErase, backarrowKey and
ptyInitialErase, and has an option in the mouse menu: Backarrow.
Putty has an option to select BACKSPACE or DELETE. But for example,
vt(1) in Plan 9 always generates BACKSPACE, and it is not configurable.

If the user wants another configuration the suckless way is config.h.

But, why do you think is better DELETE than BACKSPACE?

> The fact that you claim that matching the key codes to the labels on the
> keys are so important, yet you send the key codes associated with the
> VT220 Prior/Next/Find/Select keys when the user presses
> PageUp/PageDown/Home/End.

What ascii codes are supposed they should send? (Home sends Home, not
Find).

> That is not from the section where COLUMNS and LINES are defined (scroll
> further down the page). The table which the sentence you pasted is
> attached to also includes other variables that are _definitely_ defined
> by the standard, like TZ and HOME. LINES and COLUMNS are, for that
> matter, defined in the same section that TERM is defined in.

I just have seen them. You are right, they are defined by the standard,
but the standard doesn't define how they must be updated (this was
the part I knew, shells are not forced to set them).

> I think we
> have been talking at cross purposes, though... I was not saying,
> precisely, that it was the terminal emulator's responsibility to _set_
> them, merely to ensure they are _not_ set to values inherited from a
> different terminal, which you appeared to be rejecting.

Ok, I understand you now. Yes I agree in this point with you, and st
already unsets LINES, COLUMNS and TERMCAP. If the user needs them he
must set them in some way (maybe in his profile if he runs a login
shell), or use some program that sets them. As we already have said,
it is imposible for the terminal to set them each time the size is
changed.

We could say something similar for TERM, but it is impossible for the
system to put this variable in a terminal emulator (system take it
fomr /etc/ttys or /etc/inittab in real terminals), so I think terminal
must set it.

For the original problem, the incorrect setting of SHELL to utmp
this is the patch:

diff --git a/st.c b/st.c
index c61b90a..bcf96e9 100644
--- a/st.c
+++ b/st.c
_AT_@ -1146,7 +1146,7 @@ die(const char *errstr, ...) {
 
 void
 execsh(void) {
- char **args, *sh;
+ char **args, *sh, *prog;
         const struct passwd *pw;
         char buf[sizeof(long) * 8 + 1];
 
_AT_@ -1158,13 +1158,15 @@ execsh(void) {
                         die("who are you?\n");
         }
 
- if (utmp)
- sh = utmp;
- else if (pw->pw_shell[0])
- sh = pw->pw_shell;
+ sh = (pw->pw_shell[0]) ? pw->pw_shell : shell;
+ if(opt_cmd)
+ prog = opt_cmd[0];
+ else if(utmp)
+ prog = utmp;
         else
- sh = shell;
- args = (opt_cmd) ? opt_cmd : (char *[]){sh, NULL};
+ prog = sh;
+ args = (opt_cmd) ? opt_cmd : (char *[]) {prog, NULL};
+
         snprintf(buf, sizeof(buf), "%lu", xw.win);
 
         unsetenv("COLUMNS");
_AT_@ -1172,7 +1174,7 @@ execsh(void) {
         unsetenv("TERMCAP");
         setenv("LOGNAME", pw->pw_name, 1);
         setenv("USER", pw->pw_name, 1);
- setenv("SHELL", args[0], 1);
+ setenv("SHELL", sh, 1);
         setenv("HOME", pw->pw_dir, 1);
         setenv("TERM", termname, 1);
         setenv("WINDOWID", buf, 1);
_AT_@ -1184,7 +1186,7 @@ execsh(void) {
         signal(SIGTERM, SIG_DFL);
         signal(SIGALRM, SIG_DFL);
 
- execvp(args[0], args);
+ execvp(prog, args);
         exit(EXIT_FAILURE);
 }
 
Guys, what do you think about it?

Regards,
Received on Mon Oct 13 2014 - 20:38:27 CEST