I'm using Solaris 11.2 on a T5-2 SPARC server, and when I log in on the console (via ILOM, using PuTTY), the terminal type gets set to "sun", which is really annoying.
I've tried svccfg -s system/console-login setprop ttymon/terminal_type=xterm (followed by a reboot) and editing the /etc/profile line from TERM=sun to TERM=xterm
and still the TERM variable is "sun" when I log in. What else can I try?
On 14-12-15 10:13 AM, Kevin McGregor wrote:
I'm using Solaris 11.2 on a T5-2 SPARC server, and when I log in on the console (via ILOM, using PuTTY), the terminal type gets set to "sun", which is really annoying.
Oracle's docs (https://docs.oracle.com/cd/E23824_01/html/821-1451/modsafapp-81679.html) show a slightly different svccfg invocation:
#*svccfg -s svc:/system/console-login:default "setprop ttymon/terminal_type = xterm"*
As best I can tell, the svccfg line you used is valid for Solaris 10, not 11, but I'm not at all certain of that conclusion.
Good call. Now when I log in, TERM=xterm. However when I size the PuTTY window to 100x55 and type a long command, it still wraps it at 80 columns back to column 1 on the same line, which is not desirable. The BASH version is 4.1.11(1)-release, and the environment shows COLUMNS=80 and LINES=65 -- different from before when COLUMNS=80 and LINES=34. Try a different termtype? Any other ideas?
On Mon, Dec 15, 2014 at 10:24 AM, Adam Thompson athompso@athompso.net wrote:
On 14-12-15 10:13 AM, Kevin McGregor wrote:
I'm using Solaris 11.2 on a T5-2 SPARC server, and when I log in on the console (via ILOM, using PuTTY), the terminal type gets set to "sun", which is really annoying.
Oracle's docs ( https://docs.oracle.com/cd/E23824_01/html/821-1451/modsafapp-81679.html) show a slightly different svccfg invocation:
# *svccfg -s svc:/system/console-login:default "setprop ttymon/terminal_type = xterm"*
As best I can tell, the svccfg line you used is valid for Solaris 10, not 11, but I'm not at all certain of that conclusion.
-- -Adam Thompson athompso@athompso.net Cell: +1 204 291-7950 Fax: +1 204 489-6515
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 14-12-15 10:39 AM, Kevin McGregor wrote:
Good call. Now when I log in, TERM=xterm. However when I size the PuTTY window to 100x55 and type a long command, it still wraps it at 80 columns back to column 1 on the same line, which is not desirable. The BASH version is 4.1.11(1)-release, and the environment shows COLUMNS=80 and LINES=65 -- different from before when COLUMNS=80 and LINES=34. Try a different termtype? Any other ideas?
That's because SIGWINCH doesn't make its way through an iLO connection; regular X11 or SSH connections work fine, right?
If so, then the way to deal with it is the old "eval `resize`" technique. (More correctly, "eval $(resize)", but both work.) Note that this command is supposed to work in any shell, the resize command auto-detects whether to emit sh(1) or csh(1) lines. If you're using a non-standard shell, you may have to tell resize(1) what to emit.
Alternately, "stty cols XX rows YY" should work as well.
In some corner cases, you'll need to use stty(1) first, and then resize(1) as well (or just unset $COLUMNS and $LINES).
Nowadays, it should be reasonably safe to put this in /etc/profile:
eval $(/usr/bin/resize) && stty cols $COLUMNS rows $LINES
as all modern VT100-ish or ANSI-ish terminals respond to the escape sequences resize(1) emits, and those few that don't no longer enter weird modes as a result of them, and resize will time out in (IIRC) two seconds.
Read the comments at the top of https://ohse.de/uwe/software/resize.c.html for some background on why this is such a PITA... some software only queries the kernel ttyios for terminal size, some query the environment variables, and some query the remote terminal directly.
Another win for Adam Thompson! And another way I can fool my co-workers into thinking I'm as smart as Adam.
On Mon, Dec 15, 2014 at 10:54 AM, Adam Thompson athompso@athompso.net wrote:
On 14-12-15 10:39 AM, Kevin McGregor wrote:
Good call. Now when I log in, TERM=xterm. However when I size the PuTTY window to 100x55 and type a long command, it still wraps it at 80 columns back to column 1 on the same line, which is not desirable. The BASH version is 4.1.11(1)-release, and the environment shows COLUMNS=80 and LINES=65 -- different from before when COLUMNS=80 and LINES=34. Try a different termtype? Any other ideas?
That's because SIGWINCH doesn't make its way through an iLO connection; regular X11 or SSH connections work fine, right?
If so, then the way to deal with it is the old "eval `resize`" technique. (More correctly, "eval $(resize)", but both work.) Note that this command is supposed to work in any shell, the resize command auto-detects whether to emit sh(1) or csh(1) lines. If you're using a non-standard shell, you may have to tell resize(1) what to emit.
Alternately, "stty cols XX rows YY" should work as well.
In some corner cases, you'll need to use stty(1) first, and then resize(1) as well (or just unset $COLUMNS and $LINES).
Nowadays, it should be reasonably safe to put this in /etc/profile:
eval $(/usr/bin/resize) && stty cols $COLUMNS rows $LINES
as all modern VT100-ish or ANSI-ish terminals respond to the escape sequences resize(1) emits, and those few that don't no longer enter weird modes as a result of them, and resize will time out in (IIRC) two seconds.
Read the comments at the top of https://ohse.de/uwe/software/resize.c.html for some background on why this is such a PITA... some software only queries the kernel ttyios for terminal size, some query the environment variables, and some query the remote terminal directly.
-- -Adam Thompson athompso@athompso.net Cell: +1 204 291-7950 Fax: +1 204 489-6515
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 14-12-15 10:54 AM, Adam Thompson wrote:
Nowadays, it should be reasonably safe to put this in /etc/profile:
eval $(/usr/bin/resize) && stty cols $COLUMNS rows $LINES
Er... make that: eval $(/local/path/to/resize) && [ -n "${COLUMNS}" -a "${COLUMNS}" -gt 0 -a -n "${LINES}" -a "${LINES}" -gt 0 ] && stty cols "${COLUMNS}" rows "${LINES}"
Technically, stty accepts zero as a valid argument, but doing so would be useless.
On 2014-12-15 Adam Thompson wrote:
If so, then the way to deal with it is the old "eval `resize`" eval $(/usr/bin/resize) && stty cols $COLUMNS rows $LINES
The scary thing is that in 2014 we still have to occasionally think & worry about such things. I, too, run into the odd TUI/CLI that doesn't pick up a resize properly, for whatever non-deterministic reason. Sad.
Well, at least there's still a use for that archaic terminal knowledge we learned 25-35 years ago.
:-)