resizable serial console window?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
When using the serial console of my system I always end up with $COLUMNS=80
and $LINES=24
.
While I can change these variables manually it is somewhat annoying to do this any time when the client side terminal window has been resized.
Usually I'm connecting to the console using screen /dev/mytty baudrate
.
Changing the $TERM
environment variable to "screen" or "xterm" does not help.
Will I need to call getty
with some of those instead of vt100?
Needless to say that all of this works fine, when I connect to the same machine using ssh.
serial-console
add a comment |
When using the serial console of my system I always end up with $COLUMNS=80
and $LINES=24
.
While I can change these variables manually it is somewhat annoying to do this any time when the client side terminal window has been resized.
Usually I'm connecting to the console using screen /dev/mytty baudrate
.
Changing the $TERM
environment variable to "screen" or "xterm" does not help.
Will I need to call getty
with some of those instead of vt100?
Needless to say that all of this works fine, when I connect to the same machine using ssh.
serial-console
add a comment |
When using the serial console of my system I always end up with $COLUMNS=80
and $LINES=24
.
While I can change these variables manually it is somewhat annoying to do this any time when the client side terminal window has been resized.
Usually I'm connecting to the console using screen /dev/mytty baudrate
.
Changing the $TERM
environment variable to "screen" or "xterm" does not help.
Will I need to call getty
with some of those instead of vt100?
Needless to say that all of this works fine, when I connect to the same machine using ssh.
serial-console
When using the serial console of my system I always end up with $COLUMNS=80
and $LINES=24
.
While I can change these variables manually it is somewhat annoying to do this any time when the client side terminal window has been resized.
Usually I'm connecting to the console using screen /dev/mytty baudrate
.
Changing the $TERM
environment variable to "screen" or "xterm" does not help.
Will I need to call getty
with some of those instead of vt100?
Needless to say that all of this works fine, when I connect to the same machine using ssh.
serial-console
serial-console
edited Aug 23 '11 at 13:56
Caleb
51.8k9151194
51.8k9151194
asked Jul 13 '11 at 9:33
Sven GeggusSven Geggus
4011410
4011410
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
Like the commentators before me mentioned there is no alternative to calling resize
after every command, if you don't have this command and you don't want to install a package where it's in (xterm
), here are two POSIX shell script that do the same using ANSI terminal escape codes:
res()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33733[r33[999;999H33[6n338' > /dev/tty
IFS='[;R' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res2()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33[18t' > /dev/tty
IFS=';t' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res
is based on the solution presented at https://wiki.archlinux.org/index.php/working_with_the_serial_console#Resizing_a_terminal. It works as follows:- The cursor position is saved (
337
,DECSC
). - The cursors is moved to the most bottom-right point possible (
33[r33[999;999H
,DECSTBM
? +CUP
). - The cursor position is reported (
33[6n
,DSR
). - The cursor is moved back to the previously saved position (
338
,DECRC
).
- The cursor position is saved (
res2
is influenced byresize.sh
from xterm (see https://github.com/ThomasDickey/xterm-snapshots/blob/master/vttests/resize.sh). It uses a specificxterm
code for getting the information we want (implemented in many terminal emulators), see: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Functions-using-CSI-_-ordered-by-the-final-character_s_ ("Report the size of the text area in characters.").
BTW, in my .profile
file you will find the following:[ $(tty) = /dev/ttyS0 ] && res
so that the the terminal size is determined on every login over the serial line (the one I use for management), e.g. after you reboot the device.
See also the idea by rsaw in the comments to have the line [ $(tty) = /dev/ttyS0 ] && trap res2 DEBUG
there instead so the resizing runs after every command (note that AFAIK it's not or not always possible on busybox
though).
3
PS: To make more permanent, add[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g.,/etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).
– rsaw
Dec 30 '16 at 20:24
2
After using it for a few mins I quickly realized that bothres
&res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installingxterm
.
– rsaw
Dec 30 '16 at 20:59
2
@phk xterm'sresize
is waaaay faster -- usually 0.002sec.
– rsaw
Dec 30 '16 at 21:23
1
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in somebusybox
es seemed to be just as slow to me.
– phk
Dec 30 '16 at 21:31
1
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed soresize
is not an option.
– thom_nic
Jan 23 '17 at 17:30
|
show 1 more comment
Just for the record, here is the answer to this Problem (Usenet won):
Console Applications running inside virtual terminal applications (xterm
, rxvt
and friends) will receive SIGWINCH
after a resize operation has taken place. Thus the application will be able to redraw the window etc. in the corresponding signal handler.
Unfortunately when using a serial console, there is no such mechanism.
It is however possible for the application to actively ask for the current console Window size. So the second best thing is to do this every time a command prompt is printed by the shell.
This can be achieved by first compiling a special resize executable and then using the following in bashrc
:
if [ $(tty) == '/dev/ttyS0' ]; then
trap resize DEBUG
fi
Of course this will not change the console size settings in a console application during runtime.
1
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
1
Actually, the comment in the code makes it plain that it's not the version ofresize
which is installed on your system.
– Thomas Dickey
Feb 16 '16 at 15:23
add a comment |
"Resizable" terminals as such are a result of NAWS (Negotiate About Window Size
from RFC 1073 Telnet Window Size Option).
If you are connected directly to the computer using a serial port, there is no negotiation involved, and the computer has no direct knowledge of your terminal's screen-size.
If a terminal can negotiate the size, the computer will send SIGWINCH
to applications running in the terminal, telling them to update their notion of the screensize.
When the computer does not know the screensize, it typically sets the size shown by stty -a
(rows and columns) to zero. For interactive use, this is a little unfriendly, and some systems use environment variables LINES
and COLUMNS
to help. The values assigned may be derived from the terminal description; more often they are simply hardcoded. The convention for these variables requires that they take effect unless explicitly suppressed, e.g., in curses applications use_env
function. On the positive side, those variables can be useful when no reliable information is available. On the negative side, there is no convenient method for altering those variables.
The resize
program (a utility provided with xterm
) can use the VT100-style cursor position report escape sequence for determining the screen size. This can be run from the command-line; there is (again) no convenient way to do it automatically. As a side-effect, resize
updates the information on rows/columns seen by stty
. Its use for providing updated environment variables is mainly useful for cases such as this, where LINES
and COLUMNS
are set, and should be updated.
add a comment |
Here is another solution that worked great for me on my embedded Linux system (Overo running Angstrom). I just ran it from my .bashrc file. I didn't want to use resize because that requires installing some X packages, and I didn't want that.
Telling your Raspberry Pi that your terminal is bigger than 24 lines | Shallow Thoughts Blog
3
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
1
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
add a comment |
In case you could use FreeBSD instead, there's the resizewin(1) command, which does exactly what you want.
add a comment |
When running a shell session over a serial line it is sufficient to call the resize
command inside that session - after establishing the connection and after each terminal geometry change.
The resize
command is part of xterm but doesn't depend on X11. For example, on Fedora it's separately packaged as xterm-resize
.
How it works: the resize command measures the height/width via some cursor movements and then sends those values to the terminal via escape sequences.
With a shell like zsh this also automagically updates the LINES
and COLUMNS
variables (alternatively, one can evaluate the export statements the commands prints to stdout).
Why this is necessary: with a local or ssh session the terminal is able to signal the session about geometry changes (cf. SIGWINCH). This mechanism doesn't work over a serial connection.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f16578%2fresizable-serial-console-window%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
Like the commentators before me mentioned there is no alternative to calling resize
after every command, if you don't have this command and you don't want to install a package where it's in (xterm
), here are two POSIX shell script that do the same using ANSI terminal escape codes:
res()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33733[r33[999;999H33[6n338' > /dev/tty
IFS='[;R' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res2()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33[18t' > /dev/tty
IFS=';t' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res
is based on the solution presented at https://wiki.archlinux.org/index.php/working_with_the_serial_console#Resizing_a_terminal. It works as follows:- The cursor position is saved (
337
,DECSC
). - The cursors is moved to the most bottom-right point possible (
33[r33[999;999H
,DECSTBM
? +CUP
). - The cursor position is reported (
33[6n
,DSR
). - The cursor is moved back to the previously saved position (
338
,DECRC
).
- The cursor position is saved (
res2
is influenced byresize.sh
from xterm (see https://github.com/ThomasDickey/xterm-snapshots/blob/master/vttests/resize.sh). It uses a specificxterm
code for getting the information we want (implemented in many terminal emulators), see: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Functions-using-CSI-_-ordered-by-the-final-character_s_ ("Report the size of the text area in characters.").
BTW, in my .profile
file you will find the following:[ $(tty) = /dev/ttyS0 ] && res
so that the the terminal size is determined on every login over the serial line (the one I use for management), e.g. after you reboot the device.
See also the idea by rsaw in the comments to have the line [ $(tty) = /dev/ttyS0 ] && trap res2 DEBUG
there instead so the resizing runs after every command (note that AFAIK it's not or not always possible on busybox
though).
3
PS: To make more permanent, add[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g.,/etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).
– rsaw
Dec 30 '16 at 20:24
2
After using it for a few mins I quickly realized that bothres
&res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installingxterm
.
– rsaw
Dec 30 '16 at 20:59
2
@phk xterm'sresize
is waaaay faster -- usually 0.002sec.
– rsaw
Dec 30 '16 at 21:23
1
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in somebusybox
es seemed to be just as slow to me.
– phk
Dec 30 '16 at 21:31
1
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed soresize
is not an option.
– thom_nic
Jan 23 '17 at 17:30
|
show 1 more comment
Like the commentators before me mentioned there is no alternative to calling resize
after every command, if you don't have this command and you don't want to install a package where it's in (xterm
), here are two POSIX shell script that do the same using ANSI terminal escape codes:
res()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33733[r33[999;999H33[6n338' > /dev/tty
IFS='[;R' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res2()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33[18t' > /dev/tty
IFS=';t' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res
is based on the solution presented at https://wiki.archlinux.org/index.php/working_with_the_serial_console#Resizing_a_terminal. It works as follows:- The cursor position is saved (
337
,DECSC
). - The cursors is moved to the most bottom-right point possible (
33[r33[999;999H
,DECSTBM
? +CUP
). - The cursor position is reported (
33[6n
,DSR
). - The cursor is moved back to the previously saved position (
338
,DECRC
).
- The cursor position is saved (
res2
is influenced byresize.sh
from xterm (see https://github.com/ThomasDickey/xterm-snapshots/blob/master/vttests/resize.sh). It uses a specificxterm
code for getting the information we want (implemented in many terminal emulators), see: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Functions-using-CSI-_-ordered-by-the-final-character_s_ ("Report the size of the text area in characters.").
BTW, in my .profile
file you will find the following:[ $(tty) = /dev/ttyS0 ] && res
so that the the terminal size is determined on every login over the serial line (the one I use for management), e.g. after you reboot the device.
See also the idea by rsaw in the comments to have the line [ $(tty) = /dev/ttyS0 ] && trap res2 DEBUG
there instead so the resizing runs after every command (note that AFAIK it's not or not always possible on busybox
though).
3
PS: To make more permanent, add[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g.,/etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).
– rsaw
Dec 30 '16 at 20:24
2
After using it for a few mins I quickly realized that bothres
&res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installingxterm
.
– rsaw
Dec 30 '16 at 20:59
2
@phk xterm'sresize
is waaaay faster -- usually 0.002sec.
– rsaw
Dec 30 '16 at 21:23
1
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in somebusybox
es seemed to be just as slow to me.
– phk
Dec 30 '16 at 21:31
1
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed soresize
is not an option.
– thom_nic
Jan 23 '17 at 17:30
|
show 1 more comment
Like the commentators before me mentioned there is no alternative to calling resize
after every command, if you don't have this command and you don't want to install a package where it's in (xterm
), here are two POSIX shell script that do the same using ANSI terminal escape codes:
res()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33733[r33[999;999H33[6n338' > /dev/tty
IFS='[;R' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res2()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33[18t' > /dev/tty
IFS=';t' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res
is based on the solution presented at https://wiki.archlinux.org/index.php/working_with_the_serial_console#Resizing_a_terminal. It works as follows:- The cursor position is saved (
337
,DECSC
). - The cursors is moved to the most bottom-right point possible (
33[r33[999;999H
,DECSTBM
? +CUP
). - The cursor position is reported (
33[6n
,DSR
). - The cursor is moved back to the previously saved position (
338
,DECRC
).
- The cursor position is saved (
res2
is influenced byresize.sh
from xterm (see https://github.com/ThomasDickey/xterm-snapshots/blob/master/vttests/resize.sh). It uses a specificxterm
code for getting the information we want (implemented in many terminal emulators), see: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Functions-using-CSI-_-ordered-by-the-final-character_s_ ("Report the size of the text area in characters.").
BTW, in my .profile
file you will find the following:[ $(tty) = /dev/ttyS0 ] && res
so that the the terminal size is determined on every login over the serial line (the one I use for management), e.g. after you reboot the device.
See also the idea by rsaw in the comments to have the line [ $(tty) = /dev/ttyS0 ] && trap res2 DEBUG
there instead so the resizing runs after every command (note that AFAIK it's not or not always possible on busybox
though).
Like the commentators before me mentioned there is no alternative to calling resize
after every command, if you don't have this command and you don't want to install a package where it's in (xterm
), here are two POSIX shell script that do the same using ANSI terminal escape codes:
res()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33733[r33[999;999H33[6n338' > /dev/tty
IFS='[;R' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res2()
old=$(stty -g)
stty raw -echo min 0 time 5
printf '33[18t' > /dev/tty
IFS=';t' read -r _ rows cols _ < /dev/tty
stty "$old"
# echo "cols:$cols"
# echo "rows:$rows"
stty cols "$cols" rows "$rows"
res
is based on the solution presented at https://wiki.archlinux.org/index.php/working_with_the_serial_console#Resizing_a_terminal. It works as follows:- The cursor position is saved (
337
,DECSC
). - The cursors is moved to the most bottom-right point possible (
33[r33[999;999H
,DECSTBM
? +CUP
). - The cursor position is reported (
33[6n
,DSR
). - The cursor is moved back to the previously saved position (
338
,DECRC
).
- The cursor position is saved (
res2
is influenced byresize.sh
from xterm (see https://github.com/ThomasDickey/xterm-snapshots/blob/master/vttests/resize.sh). It uses a specificxterm
code for getting the information we want (implemented in many terminal emulators), see: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Functions-using-CSI-_-ordered-by-the-final-character_s_ ("Report the size of the text area in characters.").
BTW, in my .profile
file you will find the following:[ $(tty) = /dev/ttyS0 ] && res
so that the the terminal size is determined on every login over the serial line (the one I use for management), e.g. after you reboot the device.
See also the idea by rsaw in the comments to have the line [ $(tty) = /dev/ttyS0 ] && trap res2 DEBUG
there instead so the resizing runs after every command (note that AFAIK it's not or not always possible on busybox
though).
edited Apr 13 '17 at 12:37
Community♦
1
1
answered May 14 '16 at 21:52
phkphk
4,09852257
4,09852257
3
PS: To make more permanent, add[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g.,/etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).
– rsaw
Dec 30 '16 at 20:24
2
After using it for a few mins I quickly realized that bothres
&res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installingxterm
.
– rsaw
Dec 30 '16 at 20:59
2
@phk xterm'sresize
is waaaay faster -- usually 0.002sec.
– rsaw
Dec 30 '16 at 21:23
1
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in somebusybox
es seemed to be just as slow to me.
– phk
Dec 30 '16 at 21:31
1
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed soresize
is not an option.
– thom_nic
Jan 23 '17 at 17:30
|
show 1 more comment
3
PS: To make more permanent, add[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g.,/etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).
– rsaw
Dec 30 '16 at 20:24
2
After using it for a few mins I quickly realized that bothres
&res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installingxterm
.
– rsaw
Dec 30 '16 at 20:59
2
@phk xterm'sresize
is waaaay faster -- usually 0.002sec.
– rsaw
Dec 30 '16 at 21:23
1
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in somebusybox
es seemed to be just as slow to me.
– phk
Dec 30 '16 at 21:31
1
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed soresize
is not an option.
– thom_nic
Jan 23 '17 at 17:30
3
3
PS: To make more permanent, add
[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g., /etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).– rsaw
Dec 30 '16 at 20:24
PS: To make more permanent, add
[[ $(tty) == /dev/ttyS0 ]] && trap res2 DEBUG
to one of the shell profile configs (e.g., /etc/profile
,~/.bash_profile
). This will make it be run after every single command (which would only be a good thing if you're resizing windows/panes with screen/tmux/terminal-emulator).– rsaw
Dec 30 '16 at 20:24
2
2
After using it for a few mins I quickly realized that both
res
& res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installing xterm
.– rsaw
Dec 30 '16 at 20:59
After using it for a few mins I quickly realized that both
res
& res2
are too slow for anything but use on first-login. On my machines, they're both taking 0.5sec to finish ... making all my commands appear sluggish (when used with DEBUG trap). Whoops! Can't have that. Guess I'll be installing xterm
.– rsaw
Dec 30 '16 at 20:59
2
2
@phk xterm's
resize
is waaaay faster -- usually 0.002sec.– rsaw
Dec 30 '16 at 21:23
@phk xterm's
resize
is waaaay faster -- usually 0.002sec.– rsaw
Dec 30 '16 at 21:23
1
1
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in some
busybox
es seemed to be just as slow to me.– phk
Dec 30 '16 at 21:31
@rsaw Oh OK, good to know, I thought it would behave similar and therefore be similarly slow. I remember that the one in some
busybox
es seemed to be just as slow to me.– phk
Dec 30 '16 at 21:31
1
1
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed so
resize
is not an option.– thom_nic
Jan 23 '17 at 17:30
Thanks for this standalone solution. I'm using a console-only distro that does not have x11 or xterm installed so
resize
is not an option.– thom_nic
Jan 23 '17 at 17:30
|
show 1 more comment
Just for the record, here is the answer to this Problem (Usenet won):
Console Applications running inside virtual terminal applications (xterm
, rxvt
and friends) will receive SIGWINCH
after a resize operation has taken place. Thus the application will be able to redraw the window etc. in the corresponding signal handler.
Unfortunately when using a serial console, there is no such mechanism.
It is however possible for the application to actively ask for the current console Window size. So the second best thing is to do this every time a command prompt is printed by the shell.
This can be achieved by first compiling a special resize executable and then using the following in bashrc
:
if [ $(tty) == '/dev/ttyS0' ]; then
trap resize DEBUG
fi
Of course this will not change the console size settings in a console application during runtime.
1
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
1
Actually, the comment in the code makes it plain that it's not the version ofresize
which is installed on your system.
– Thomas Dickey
Feb 16 '16 at 15:23
add a comment |
Just for the record, here is the answer to this Problem (Usenet won):
Console Applications running inside virtual terminal applications (xterm
, rxvt
and friends) will receive SIGWINCH
after a resize operation has taken place. Thus the application will be able to redraw the window etc. in the corresponding signal handler.
Unfortunately when using a serial console, there is no such mechanism.
It is however possible for the application to actively ask for the current console Window size. So the second best thing is to do this every time a command prompt is printed by the shell.
This can be achieved by first compiling a special resize executable and then using the following in bashrc
:
if [ $(tty) == '/dev/ttyS0' ]; then
trap resize DEBUG
fi
Of course this will not change the console size settings in a console application during runtime.
1
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
1
Actually, the comment in the code makes it plain that it's not the version ofresize
which is installed on your system.
– Thomas Dickey
Feb 16 '16 at 15:23
add a comment |
Just for the record, here is the answer to this Problem (Usenet won):
Console Applications running inside virtual terminal applications (xterm
, rxvt
and friends) will receive SIGWINCH
after a resize operation has taken place. Thus the application will be able to redraw the window etc. in the corresponding signal handler.
Unfortunately when using a serial console, there is no such mechanism.
It is however possible for the application to actively ask for the current console Window size. So the second best thing is to do this every time a command prompt is printed by the shell.
This can be achieved by first compiling a special resize executable and then using the following in bashrc
:
if [ $(tty) == '/dev/ttyS0' ]; then
trap resize DEBUG
fi
Of course this will not change the console size settings in a console application during runtime.
Just for the record, here is the answer to this Problem (Usenet won):
Console Applications running inside virtual terminal applications (xterm
, rxvt
and friends) will receive SIGWINCH
after a resize operation has taken place. Thus the application will be able to redraw the window etc. in the corresponding signal handler.
Unfortunately when using a serial console, there is no such mechanism.
It is however possible for the application to actively ask for the current console Window size. So the second best thing is to do this every time a command prompt is printed by the shell.
This can be achieved by first compiling a special resize executable and then using the following in bashrc
:
if [ $(tty) == '/dev/ttyS0' ]; then
trap resize DEBUG
fi
Of course this will not change the console size settings in a console application during runtime.
edited Mar 14 at 10:03
ndemou
631717
631717
answered Aug 23 '11 at 13:49
Sven GeggusSven Geggus
4011410
4011410
1
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
1
Actually, the comment in the code makes it plain that it's not the version ofresize
which is installed on your system.
– Thomas Dickey
Feb 16 '16 at 15:23
add a comment |
1
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
1
Actually, the comment in the code makes it plain that it's not the version ofresize
which is installed on your system.
– Thomas Dickey
Feb 16 '16 at 15:23
1
1
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
Shouldn’t it be possible to run a protocol over the serial line, that does offer all the features? I mean we do have a client and a server. They could use inband escape sequences to do just about everything, and still work with a plain text serial console!
– Evi1M4chine
Feb 2 '16 at 14:35
1
1
Actually, the comment in the code makes it plain that it's not the version of
resize
which is installed on your system.– Thomas Dickey
Feb 16 '16 at 15:23
Actually, the comment in the code makes it plain that it's not the version of
resize
which is installed on your system.– Thomas Dickey
Feb 16 '16 at 15:23
add a comment |
"Resizable" terminals as such are a result of NAWS (Negotiate About Window Size
from RFC 1073 Telnet Window Size Option).
If you are connected directly to the computer using a serial port, there is no negotiation involved, and the computer has no direct knowledge of your terminal's screen-size.
If a terminal can negotiate the size, the computer will send SIGWINCH
to applications running in the terminal, telling them to update their notion of the screensize.
When the computer does not know the screensize, it typically sets the size shown by stty -a
(rows and columns) to zero. For interactive use, this is a little unfriendly, and some systems use environment variables LINES
and COLUMNS
to help. The values assigned may be derived from the terminal description; more often they are simply hardcoded. The convention for these variables requires that they take effect unless explicitly suppressed, e.g., in curses applications use_env
function. On the positive side, those variables can be useful when no reliable information is available. On the negative side, there is no convenient method for altering those variables.
The resize
program (a utility provided with xterm
) can use the VT100-style cursor position report escape sequence for determining the screen size. This can be run from the command-line; there is (again) no convenient way to do it automatically. As a side-effect, resize
updates the information on rows/columns seen by stty
. Its use for providing updated environment variables is mainly useful for cases such as this, where LINES
and COLUMNS
are set, and should be updated.
add a comment |
"Resizable" terminals as such are a result of NAWS (Negotiate About Window Size
from RFC 1073 Telnet Window Size Option).
If you are connected directly to the computer using a serial port, there is no negotiation involved, and the computer has no direct knowledge of your terminal's screen-size.
If a terminal can negotiate the size, the computer will send SIGWINCH
to applications running in the terminal, telling them to update their notion of the screensize.
When the computer does not know the screensize, it typically sets the size shown by stty -a
(rows and columns) to zero. For interactive use, this is a little unfriendly, and some systems use environment variables LINES
and COLUMNS
to help. The values assigned may be derived from the terminal description; more often they are simply hardcoded. The convention for these variables requires that they take effect unless explicitly suppressed, e.g., in curses applications use_env
function. On the positive side, those variables can be useful when no reliable information is available. On the negative side, there is no convenient method for altering those variables.
The resize
program (a utility provided with xterm
) can use the VT100-style cursor position report escape sequence for determining the screen size. This can be run from the command-line; there is (again) no convenient way to do it automatically. As a side-effect, resize
updates the information on rows/columns seen by stty
. Its use for providing updated environment variables is mainly useful for cases such as this, where LINES
and COLUMNS
are set, and should be updated.
add a comment |
"Resizable" terminals as such are a result of NAWS (Negotiate About Window Size
from RFC 1073 Telnet Window Size Option).
If you are connected directly to the computer using a serial port, there is no negotiation involved, and the computer has no direct knowledge of your terminal's screen-size.
If a terminal can negotiate the size, the computer will send SIGWINCH
to applications running in the terminal, telling them to update their notion of the screensize.
When the computer does not know the screensize, it typically sets the size shown by stty -a
(rows and columns) to zero. For interactive use, this is a little unfriendly, and some systems use environment variables LINES
and COLUMNS
to help. The values assigned may be derived from the terminal description; more often they are simply hardcoded. The convention for these variables requires that they take effect unless explicitly suppressed, e.g., in curses applications use_env
function. On the positive side, those variables can be useful when no reliable information is available. On the negative side, there is no convenient method for altering those variables.
The resize
program (a utility provided with xterm
) can use the VT100-style cursor position report escape sequence for determining the screen size. This can be run from the command-line; there is (again) no convenient way to do it automatically. As a side-effect, resize
updates the information on rows/columns seen by stty
. Its use for providing updated environment variables is mainly useful for cases such as this, where LINES
and COLUMNS
are set, and should be updated.
"Resizable" terminals as such are a result of NAWS (Negotiate About Window Size
from RFC 1073 Telnet Window Size Option).
If you are connected directly to the computer using a serial port, there is no negotiation involved, and the computer has no direct knowledge of your terminal's screen-size.
If a terminal can negotiate the size, the computer will send SIGWINCH
to applications running in the terminal, telling them to update their notion of the screensize.
When the computer does not know the screensize, it typically sets the size shown by stty -a
(rows and columns) to zero. For interactive use, this is a little unfriendly, and some systems use environment variables LINES
and COLUMNS
to help. The values assigned may be derived from the terminal description; more often they are simply hardcoded. The convention for these variables requires that they take effect unless explicitly suppressed, e.g., in curses applications use_env
function. On the positive side, those variables can be useful when no reliable information is available. On the negative side, there is no convenient method for altering those variables.
The resize
program (a utility provided with xterm
) can use the VT100-style cursor position report escape sequence for determining the screen size. This can be run from the command-line; there is (again) no convenient way to do it automatically. As a side-effect, resize
updates the information on rows/columns seen by stty
. Its use for providing updated environment variables is mainly useful for cases such as this, where LINES
and COLUMNS
are set, and should be updated.
answered Feb 17 '16 at 10:33
Thomas DickeyThomas Dickey
54.3k5106181
54.3k5106181
add a comment |
add a comment |
Here is another solution that worked great for me on my embedded Linux system (Overo running Angstrom). I just ran it from my .bashrc file. I didn't want to use resize because that requires installing some X packages, and I didn't want that.
Telling your Raspberry Pi that your terminal is bigger than 24 lines | Shallow Thoughts Blog
3
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
1
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
add a comment |
Here is another solution that worked great for me on my embedded Linux system (Overo running Angstrom). I just ran it from my .bashrc file. I didn't want to use resize because that requires installing some X packages, and I didn't want that.
Telling your Raspberry Pi that your terminal is bigger than 24 lines | Shallow Thoughts Blog
3
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
1
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
add a comment |
Here is another solution that worked great for me on my embedded Linux system (Overo running Angstrom). I just ran it from my .bashrc file. I didn't want to use resize because that requires installing some X packages, and I didn't want that.
Telling your Raspberry Pi that your terminal is bigger than 24 lines | Shallow Thoughts Blog
Here is another solution that worked great for me on my embedded Linux system (Overo running Angstrom). I just ran it from my .bashrc file. I didn't want to use resize because that requires installing some X packages, and I didn't want that.
Telling your Raspberry Pi that your terminal is bigger than 24 lines | Shallow Thoughts Blog
edited Mar 3 '18 at 8:39
Drakonoved
7131724
7131724
answered May 2 '14 at 22:02
Austin BeerAustin Beer
391
391
3
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
1
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
add a comment |
3
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
1
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
3
3
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
Please don't just post a link: include the relevant detail so that the information is available here as well...
– jasonwryan
May 3 '14 at 0:51
1
1
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
Too bad it needs Python.
– Craig McQueen
Oct 31 '14 at 4:52
add a comment |
In case you could use FreeBSD instead, there's the resizewin(1) command, which does exactly what you want.
add a comment |
In case you could use FreeBSD instead, there's the resizewin(1) command, which does exactly what you want.
add a comment |
In case you could use FreeBSD instead, there's the resizewin(1) command, which does exactly what you want.
In case you could use FreeBSD instead, there's the resizewin(1) command, which does exactly what you want.
edited Mar 3 '18 at 8:30
Sparhawk
10.3k744101
10.3k744101
answered Nov 6 '17 at 11:13
Edward Tomasz NapieralaEdward Tomasz Napierala
1,0381510
1,0381510
add a comment |
add a comment |
When running a shell session over a serial line it is sufficient to call the resize
command inside that session - after establishing the connection and after each terminal geometry change.
The resize
command is part of xterm but doesn't depend on X11. For example, on Fedora it's separately packaged as xterm-resize
.
How it works: the resize command measures the height/width via some cursor movements and then sends those values to the terminal via escape sequences.
With a shell like zsh this also automagically updates the LINES
and COLUMNS
variables (alternatively, one can evaluate the export statements the commands prints to stdout).
Why this is necessary: with a local or ssh session the terminal is able to signal the session about geometry changes (cf. SIGWINCH). This mechanism doesn't work over a serial connection.
add a comment |
When running a shell session over a serial line it is sufficient to call the resize
command inside that session - after establishing the connection and after each terminal geometry change.
The resize
command is part of xterm but doesn't depend on X11. For example, on Fedora it's separately packaged as xterm-resize
.
How it works: the resize command measures the height/width via some cursor movements and then sends those values to the terminal via escape sequences.
With a shell like zsh this also automagically updates the LINES
and COLUMNS
variables (alternatively, one can evaluate the export statements the commands prints to stdout).
Why this is necessary: with a local or ssh session the terminal is able to signal the session about geometry changes (cf. SIGWINCH). This mechanism doesn't work over a serial connection.
add a comment |
When running a shell session over a serial line it is sufficient to call the resize
command inside that session - after establishing the connection and after each terminal geometry change.
The resize
command is part of xterm but doesn't depend on X11. For example, on Fedora it's separately packaged as xterm-resize
.
How it works: the resize command measures the height/width via some cursor movements and then sends those values to the terminal via escape sequences.
With a shell like zsh this also automagically updates the LINES
and COLUMNS
variables (alternatively, one can evaluate the export statements the commands prints to stdout).
Why this is necessary: with a local or ssh session the terminal is able to signal the session about geometry changes (cf. SIGWINCH). This mechanism doesn't work over a serial connection.
When running a shell session over a serial line it is sufficient to call the resize
command inside that session - after establishing the connection and after each terminal geometry change.
The resize
command is part of xterm but doesn't depend on X11. For example, on Fedora it's separately packaged as xterm-resize
.
How it works: the resize command measures the height/width via some cursor movements and then sends those values to the terminal via escape sequences.
With a shell like zsh this also automagically updates the LINES
and COLUMNS
variables (alternatively, one can evaluate the export statements the commands prints to stdout).
Why this is necessary: with a local or ssh session the terminal is able to signal the session about geometry changes (cf. SIGWINCH). This mechanism doesn't work over a serial connection.
answered Mar 7 '18 at 14:39
maxschlepzigmaxschlepzig
34.7k33141214
34.7k33141214
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f16578%2fresizable-serial-console-window%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown