jdn@mas.UUCP (Jeff Nisewanger) (04/26/89)
I'm confused. On BSD 4.3 Unix reset(1) is a link to tset(1). When the binary is executed it checks its invocation name (in other words argv[0]) to see if the name is "reset" and if it is then among other things it checks the terminal's "rs" and "rf" termcap capabilities and sends them to the terminal to re-initialize the terminal state. If its invocation name is "tset" then it uses the "is" and "if" (initialization string and initialization file) capabilities instead. In particular the termcap entry for a vt100 only has the "rf" capability and not the "if" (WHY?). The "rf" entry points to "/usr/lib/tabset/vt100" which is a file with magic terminal codes in it to set tab stops. This means that if I want my terminals tab stops to be set to something sensible I have to run "reset". OK. I find that on our Ultrix distribution, Ultrix-32 V3.0 (Rev 64) UWS V2.0, that /usr/ucb/reset is NOT a link to /usr/ucb/tset but is instead a 4096 byte binary. By running strings(1) on it and temporarily cp'ing /bin/echo to /usr/ucb/tset I find that it seems to just mindlessly execl "tset -Q -I". WHAT IS GOING ON HERE?!?!?! Why is this different from 4.x BSD? In fact, as far as I can tell without source code, tset hasn't been changed. Tset(1) still checks to see if it is being invoked as reset! However because of this strange Ultrix reset binary /usr/ucb/tset will NEVER be invoked as "reset" (and therefore never use the "rf" and "rs" capabilities). In fact if I remove Ultrix's /usr/ucb/reset and instead "ln /usr/ucb/tset /usr/ucb/reset" everything works just great. Suddenly reset(1) starts working just like its documented to and outputs my vt100 "rf" termcap capability thereby fixing my tab stops. Can someone please explain this total weirdness. P.S. Does anyone know why the termcap vt100 entry has an "rf" capability but no "if". Or why the vt125 entry has an "if" entry but no "rf"? Jeff Nisewanger Measurex Automation Systems