On Mon, Oct 13, 2014, at 14:38, k0ga_AT_shike2.com wrote:
> > 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).
What is Home?
> > 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,
>
>
--
Random832
Received on Mon Oct 13 2014 - 22:12:48 CEST