Re: bin/56496: etcupdate(8) merge formatting issue

[RVP <rvp%SDF.ORG@localhost>]

The following reply was made to PR bin/56496; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/56496: etcupdate(8) merge formatting issue
Date: Fri, 19 Nov 2021 22:15:33 +0000 (UTC)

 On Fri, 19 Nov 2021, Hauke Fath wrote:
 
 > On Thu, 18 Nov 2021 22:40:01 +0000 (UTC), RVP wrote:
 >
 >>  If that tset command is in /etc/csh.login, then all (login-shell) uses of
 >>  csh would show this issue--provided `-oxtabs' is _also_ set.
 >
 > Which the tset command does, for whatever reason.
 >
 > [...]
 >
 > Would it make sense to follow the eval `tset ...` with an 'stty oxtabs'
 > for (at least) TERM == xterm, or would I incur any more side-effects?
 >
 
 As an FYI,
 
 a) getty also sets `-oxtabs' for virtual terminals, and,
 
 b) xterm, by default, tries to copy the settings of whatever terminal it
      was started from.
 
 The combination of a) and b) can have surprising effects.
 
 Try this first:
 
 $ stty oxtabs; xterm; stty -oxtabs; xterm
 
 Do a `stty -a | fgrep oxtabs' in each xterm instance and see how xterm
 copies the current terminal setting.
 
 Now, starting from the top (or, bottom):
 
 1. When a TTY is opened, the kernel applies some default settings
      which can be seen in
 
   	/usr/include/sys/ttydefaults.h
 
      For output, the NetBSD kernel sets `oxtabs' (see: TTYDEF_OFLAG);
 
      FreeBSD sets `tab0' aka. `-oxtabs'.
 
      Linux also has a <sys/ttydefaults.h> file, but, that is just
      there for compatibility's sake--the actual settings are hard-coded
      in the driver (`tab0').
 
 2. getty opens, say, /dev/ttyE0 and sets `-oxtabs' as per /etc/gettytab
 
 3. In ~/.xinitrc you have something like:
 
   	...
   	xterm -g 100x35 -fn 10x20 -fg Ivory -bg Black ... &
   	exec evilwm
 
 Here that xterm will inherit `-oxtabs' from /dev/ttyE0, but, another
 xterm started in a different way may not: my WM is evilwm and you
 can create a new xterm window any time using Ctrl-Alt-Enter. To do
 that evilwm does this:
 
        39 void spawn(const char *const cmd[]) {
   	...
        45         if (!(pid = fork())) {
        46                 // Put first fork in a new session
        47                 setsid();
        48                 switch (fork()) {
   	...
        54                         case 0: execvp("xterm" ...); break;
        55                         default: _exit(0);
 
 That setsid() loses whatever terminal evilwm had and xterm will
 therefore inherit the default applied by the kernel which is
 `oxtabs'.  So, now I have 2 xterm windows running side-by-side,
 one with `-oxtabs' set and the other with `oxtabs' and programs
 behaving in subtly different ways in each as a consequence. (And
 the same program behaving differently on FreeBSD and Linux compared
 with NetBSD.) This bit me some time ago, so now I nail down tab
 behaviour using:
 
 XTerm*ttyModes:         tabs
 
 in ~/.Xresources to always set `-oxtabs'
 
 You can work out what will happen in other situations:
 
 - xterm started with or without a login shell
     (login shell runs `tset -s ...'; normal shell doesn't);
 
 - user starts X via xinit instead of startx
     (so no initial TTY)
 
 - etc ...
 
 -RVP