Discussion:
How do I get vi to know my window size?
Dave Hylands
2006-09-19 02:54:11 UTC
Permalink
Hi,

I'm using busybox-1.1.2 under linux-2.6.17 on a gumstix.

When I run the vi from busybox over my serial line, it thinks that my
terminal is 80x24

My vi config options are set like this:
CONFIG_VI=y
CONFIG_FEATURE_VI_COLON=y
# CONFIG_FEATURE_VI_YANKMARK is not set
CONFIG_FEATURE_VI_SEARCH=y
CONFIG_FEATURE_VI_USE_SIGNALS=y
# CONFIG_FEATURE_VI_DOT_CMD is not set
# CONFIG_FEATURE_VI_READONLY is not set
# CONFIG_FEATURE_VI_SETOPTS is not set
# CONFIG_FEATURE_VI_SET is not set
CONFIG_FEATURE_VI_WIN_RESIZE=y
# CONFIG_FEATURE_VI_OPTIMIZE_CURSOR is not set

I dug through the code a bit to find the get_terminal_width_height function.

I then coded up a simple test program:

#include <stdio.h>
#include <termios.h>
#include <sys/ioctl.h>

int main( int argc, char **argv )
{
struct winsize win = { 0, 0, 0, 0 };
int ret = ioctl(fileno(stdin), TIOCGWINSZ, &win);

printf( "Width = %d, Height = %d\n", win.ws_col, win.ws_row );
return 0;
}

and when I run it, it reports 0 and 0 (which explains why
get_teminal_width_height reports 80x24).

If I ssh into the gumstix then running the above program reports the
correct size, and running vi works as expected.

My terminal type in both cases is vt100, and the TERM environment
variable is set appropriately.

So, is it possible to get the terminal size correct when using a serial port?

Any insight would be appreciated.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
Adam Hawes
2006-09-19 03:52:02 UTC
Permalink
Post by Dave Hylands
So, is it possible to get the terminal size correct when
using a serial port?
I don't believe it is. This works with SSH (and Telnet) because
ssh supports sending and receiving the terminal size from the client.
Serial consoles are dumb. They receive bits and echo them to the
terminal; VT100 ones at least.

You might be able to coax it into using ANSI terminal emulation
but you'd still need that on the serverb side.

Your best option is to work out your terminal size and configure
your environment accordingly when you log in - not that I know how
to do that. Most of my serial console work involves
'tail -f /var/log/messages'

A
Steven Scholz
2006-09-19 09:19:19 UTC
Permalink
Dave,
Post by Dave Hylands
So, is it possible to get the terminal size correct when using a serial port?
Any insight would be appreciated.
Is it an option for you the _set_ the terminal size using "stty rows" and
"stty cols" in some startup script?

--
Steven
Paul Fox
2006-09-19 10:05:13 UTC
Permalink
Post by Adam Hawes
Post by Dave Hylands
So, is it possible to get the terminal size correct when
using a serial port?
I don't believe it is. This works with SSH (and Telnet) because
ssh supports sending and receiving the terminal size from the client.
right. the best solution i've come up with is to use (a stripped down
version of) the "resize" program that i believe is, or was, distributed
with xterm. it uses an ansi query seqeunce to ask the terminal how
big it is, and then sets the tty driver's notion of the size correctly
based on that inforomation. always works reliably for me.

i have a feeling i may already have posted the code i'm using, or
a reference to it, to the list a while back. check the archives, or
ask me for a copy -- it's only a few pages long. for copyright
conflict reasons it can't become an applet, though it would be nifty if
someone would rewrite it so that it could be included in busybox.

paul
=---------------------
paul fox, pgf at brightstareng.com
Dave Hylands
2006-09-19 17:27:52 UTC
Permalink
Hi,
Post by Paul Fox
Post by Adam Hawes
Post by Dave Hylands
So, is it possible to get the terminal size correct when
using a serial port?
I don't believe it is. This works with SSH (and Telnet) because
ssh supports sending and receiving the terminal size from the client.
right. the best solution i've come up with is to use (a stripped down
version of) the "resize" program that i believe is, or was, distributed
with xterm. it uses an ansi query seqeunce to ask the terminal how
big it is, and then sets the tty driver's notion of the size correctly
based on that inforomation. always works reliably for me.
I just thought I'd report that Paul sent me a copy of his resize
utility and it works perfectly.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
Rob Landley
2006-09-19 21:11:38 UTC
Permalink
Post by Paul Fox
i have a feeling i may already have posted the code i'm using, or
a reference to it, to the list a while back. check the archives, or
ask me for a copy -- it's only a few pages long. for copyright
conflict reasons it can't become an applet, though it would be nifty if
someone would rewrite it so that it could be included in busybox.
Who exactly are you testing the current size _from_? (Is your xterm
responding to the ansi escape sequence when it tries to display it?) If so,
I could just add this behavior as a config option to
get_terminal_width_height() in libbb (a fallback for when we get 0/0 as the
size). The hard part's figuring out when it's safe to do it. (Hmmm, poll
with an immediate timeout on stdin and only do it if no input is waiting, to
avoid getting confused by "echo blah | program"... And then you'd need a
similar poll with quick timeout on the read, but how quick is quick? It
should definitely fall back to reading the environment variables $LINES and
$COLUMNS _first_ before trying an ANSI probe. And it would miss resizes
after the program started...)

Hmmm...

(Talking about ANSI escape sequences always brings back memories. (One of my
first original C programs was an ansi screen driver (doing the whole direct
screen writes under dos thing many times faster than the bios did) back in
1990. Before that, I mostly modified existing C programs, or wrote original
ones in Commodore 64 BASIC. :) I remember I had a file over 100k long (don't
laugh, it was a lot back then) a session capture of viewing lots of
consecutive messages from the WWIVnet Ansi Art Gallery. I used it to test my
code for correctness, and later as a performance benchmark. I'm glad
that "echo -e '\e[8m'" doesn't work in Linux. Or "\e[...p" to attach macros
to keyboard keys. Now _there_ was a fun security issue...)

Let's see, the sequence to do this would be something like... (Googles for
_extremely_ old references...) echo -e "\e[s\e[999C\e[999B\e[6n\e[u"
And then poll with a half-second timeout for the response string (looping on
short reads until we get the R or a timeout). Hmmm... What code queries for
a TTY again?

Putters off to look at code...

Rob
--
Never bet against the cheap plastic solution.
Dave Hylands
2006-09-19 17:27:52 UTC
Permalink
Hi,
Post by Paul Fox
Post by Adam Hawes
Post by Dave Hylands
So, is it possible to get the terminal size correct when
using a serial port?
I don't believe it is. This works with SSH (and Telnet) because
ssh supports sending and receiving the terminal size from the client.
right. the best solution i've come up with is to use (a stripped down
version of) the "resize" program that i believe is, or was, distributed
with xterm. it uses an ansi query seqeunce to ask the terminal how
big it is, and then sets the tty driver's notion of the size correctly
based on that inforomation. always works reliably for me.
I just thought I'd report that Paul sent me a copy of his resize
utility and it works perfectly.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
Rob Landley
2006-09-19 21:11:38 UTC
Permalink
Post by Paul Fox
i have a feeling i may already have posted the code i'm using, or
a reference to it, to the list a while back. check the archives, or
ask me for a copy -- it's only a few pages long. for copyright
conflict reasons it can't become an applet, though it would be nifty if
someone would rewrite it so that it could be included in busybox.
Who exactly are you testing the current size _from_? (Is your xterm
responding to the ansi escape sequence when it tries to display it?) If so,
I could just add this behavior as a config option to
get_terminal_width_height() in libbb (a fallback for when we get 0/0 as the
size). The hard part's figuring out when it's safe to do it. (Hmmm, poll
with an immediate timeout on stdin and only do it if no input is waiting, to
avoid getting confused by "echo blah | program"... And then you'd need a
similar poll with quick timeout on the read, but how quick is quick? It
should definitely fall back to reading the environment variables $LINES and
$COLUMNS _first_ before trying an ANSI probe. And it would miss resizes
after the program started...)

Hmmm...

(Talking about ANSI escape sequences always brings back memories. (One of my
first original C programs was an ansi screen driver (doing the whole direct
screen writes under dos thing many times faster than the bios did) back in
1990. Before that, I mostly modified existing C programs, or wrote original
ones in Commodore 64 BASIC. :) I remember I had a file over 100k long (don't
laugh, it was a lot back then) a session capture of viewing lots of
consecutive messages from the WWIVnet Ansi Art Gallery. I used it to test my
code for correctness, and later as a performance benchmark. I'm glad
that "echo -e '\e[8m'" doesn't work in Linux. Or "\e[...p" to attach macros
to keyboard keys. Now _there_ was a fun security issue...)

Let's see, the sequence to do this would be something like... (Googles for
_extremely_ old references...) echo -e "\e[s\e[999C\e[999B\e[6n\e[u"
And then poll with a half-second timeout for the response string (looping on
short reads until we get the R or a timeout). Hmmm... What code queries for
a TTY again?

Putters off to look at code...

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-19 16:49:18 UTC
Permalink
Post by Dave Hylands
Hi,
I'm using busybox-1.1.2 under linux-2.6.17 on a gumstix.
When I run the vi from busybox over my serial line, it thinks that my
terminal is 80x24
http://www.busybox.net/lists/busybox/2006-June/022850.html

As you discovered...
Post by Dave Hylands
If I ssh into the gumstix then running the above program reports the
correct size, and running vi works as expected.
Because ssh is setting up a pty.
Post by Dave Hylands
My terminal type in both cases is vt100, and the TERM environment
variable is set appropriately.
$TERM doesn't tell you size.
Post by Dave Hylands
So, is it possible to get the terminal size correct when using a serial port?
Any insight would be appreciated.
Try:

stty columns 80 rows 25

Rob
--
Never bet against the cheap plastic solution.
Paul Fox
2006-09-20 07:51:41 UTC
Permalink
Post by Rob Landley
Who exactly are you testing the current size _from_? (Is your xterm
responding to the ansi escape sequence when it tries to display it?) If so,
yes, exactly right. the code i have sends this:
ESC "7" ESC "[r" ESC "[999;999H" ESC "[6n"
then reads a response that looks like:
ESC "[%d;%dR"
and uses the results to feed TIOCSWINSZ. then send:
ESC "8"

the timeout on the read is long -- 10 seconds -- but it's a standalone
program, and can be killed if the terminal isn't responding.
Post by Rob Landley
I could just add this behavior as a config option to
get_terminal_width_height() in libbb (a fallback for when we get 0/0 as the
size). The hard part's figuring out when it's safe to do it. (Hmmm, poll
i agree, though one might come up with a mechanism that could be turned
on optionally by the calling program.

paul
=---------------------
paul fox, pgf at brightstareng.com
Rob Landley
2006-09-20 23:49:33 UTC
Permalink
Post by Paul Fox
i agree, though one might come up with a mechanism that could be turned
on optionally by the calling program.
Actually, the correct place to do this is in bbsh when it's interactive.

Our existing terminal checking code should be taught about $LINES and
$COLUMNS, and should check them as a fallback for when the ioctl returns 0.
That's a small enough amount of bloat to be acceptable in exchange for the
functionality, it's basically atoi(getenv("LINES"))...

I added it (svn 16167). Dunno if it works, have to set up a test environment
that hasn't got a controlling terminal but has $LINES and $COLUMNS set...

Anyway, I can teach bbsh that when it's launched interactive, do the probing
thing if standard querying doesn't work to determine terminal size. That'll
set $LINES and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...

Rob
--
Never bet against the cheap plastic solution.
Rich Felker
2006-09-21 01:53:17 UTC
Permalink
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched interactive, do the probing
thing if standard querying doesn't work to determine terminal size. That'll
set $LINES and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user keystrokes
already in the input buffer? The only way I can think to avoid that is
with some sort of tricky extra buffering layer. Maybe it doesn't
matter but I find it annoying if I've typed ahead before a program
starts and some of the keystrokes get lost.

Rich
Rob Landley
2006-09-21 19:17:53 UTC
Permalink
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched interactive, do the probing
thing if standard querying doesn't work to determine terminal size.
That'll
Post by Rich Felker
Post by Rob Landley
set $LINES and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user keystrokes
already in the input buffer?
You poll() and either don't do it or read them first. It's a heuristic,
working around the general badness of in-band signaling. It's not going to
be perfect.
Post by Rich Felker
The only way I can think to avoid that is
with some sort of tricky extra buffering layer.
No, poll() with a timeout of 0 and skip if the heuristic if there's input
waiting. You also need to do something like that if somebody goes "cat
script | bbsh". (And you want to make sure that stdin and stdout point to
the same device, although that's part of the standard "interactive" check,
hence doing this when you're in interactive mode. There was more, I thought
this through on the busride home yesterday, my notes around around here
somewhere...)

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-21 19:17:53 UTC
Permalink
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched interactive, do the probing
thing if standard querying doesn't work to determine terminal size.
That'll
Post by Rich Felker
Post by Rob Landley
set $LINES and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user keystrokes
already in the input buffer?
You poll() and either don't do it or read them first. It's a heuristic,
working around the general badness of in-band signaling. It's not going to
be perfect.
Post by Rich Felker
The only way I can think to avoid that is
with some sort of tricky extra buffering layer.
No, poll() with a timeout of 0 and skip if the heuristic if there's input
waiting. You also need to do something like that if somebody goes "cat
script | bbsh". (And you want to make sure that stdin and stdout point to
the same device, although that's part of the standard "interactive" check,
hence doing this when you're in interactive mode. There was more, I thought
this through on the busride home yesterday, my notes around around here
somewhere...)

Rob
--
Never bet against the cheap plastic solution.
Rich Felker
2006-09-21 01:53:17 UTC
Permalink
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched interactive, do the probing
thing if standard querying doesn't work to determine terminal size. That'll
set $LINES and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user keystrokes
already in the input buffer? The only way I can think to avoid that is
with some sort of tricky extra buffering layer. Maybe it doesn't
matter but I find it annoying if I've typed ahead before a program
starts and some of the keystrokes get lost.

Rich
Bernhard Fischer
2006-09-21 17:13:20 UTC
Permalink
Post by Paul Fox
Post by Rob Landley
Who exactly are you testing the current size _from_? (Is your xterm
responding to the ansi escape sequence when it tries to display it?) If so,
ESC "7" ESC "[r" ESC "[999;999H" ESC "[6n"
ESC "[%d;%dR"
ESC "8"
Now that's about all one needs to know :)

The only inconvenient stuff is the termios flags for echo et. al.

Not really tested.. Can someone who initially faced the problem
give it a whirl, please?
TIA,

PS: before somebody asks for a "reset" applet, please consider using
either this alias or write a fancy script to that effect.

$ grep reset ~/.bashrc
# alias reset='echo -e '\''\033c'\'' ; stty sane line 1'

cheers,
Bernhard
Post by Paul Fox
the timeout on the read is long -- 10 seconds -- but it's a standalone
program, and can be killed if the terminal isn't responding.
Post by Rob Landley
I could just add this behavior as a config option to
get_terminal_width_height() in libbb (a fallback for when we get 0/0 as the
size). The hard part's figuring out when it's safe to do it. (Hmmm, poll
i agree, though one might come up with a mechanism that could be turned
on optionally by the calling program.
paul
=---------------------
paul fox, pgf at brightstareng.com
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resize.c
Type: text/x-csrc
Size: 1193 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20060921/dbcc307b/attachment.c
Rich Felker
2006-09-21 17:38:18 UTC
Permalink
/* Copyright 2006 Bernhard Fischer
* Licensed under GPLv2 or (at landleys or your opinion) any later version.
* Have fun or somesuch.
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <stdlib.h>
static struct termios old;
static void reset_to_old(void) {
tcsetattr(0, TCSANOW, &old);
}
int main(void) {
/* save_cursor_pos 7
* scroll_whole_screen [r
* put_cursor_waaaay_off [$x;$yH
* get_cursor_pos [6n
* restore_cursor_pos 8
*/
const char req[] = "\0337\033[r\033[999;999H\033[6n";
FILE *fp = fopen("/dev/stdin", "r+");
int f = fileno(fp);
Umm, this code is rather silly, and depends on /proc. Why not use
/dev/tty or if you really mean stdin, use fdopen(0)...?
struct winsize w = {0,0,0,0};
int ret;
struct termios new;
tcgetattr(0, &old); /* fiddle echo */
new = old;
new.c_cflag |= (CLOCAL | CREAD);
new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
#if defined(TIMEOUT) && (TIMEOUT >=1)
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = TIMEOUT;
#endif
tcsetattr(0, TCSANOW, &new);
atexit(reset_to_old);
Using atexit() is not useful unless you call exit() from somewhere in
the program. Default fatal signal handlers cannot call atexit handlers
for you because they take place at the kernel level so you need to
handle them yourself if you want to.

Keep in mind that for static linking, atexit could add a lot of size
to the program too. So can scanf/printf. The program hardly uses stdio
as written and it should be easy to make it not depend on stdio at
all..

Rich
Bernhard Fischer
2006-09-21 17:35:52 UTC
Permalink
Post by Rich Felker
/* Copyright 2006 Bernhard Fischer
* Licensed under GPLv2 or (at landleys or your opinion) any later version.
* Have fun or somesuch.
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <stdlib.h>
static struct termios old;
static void reset_to_old(void) {
tcsetattr(0, TCSANOW, &old);
}
int main(void) {
/* save_cursor_pos 7
* scroll_whole_screen [r
* put_cursor_waaaay_off [$x;$yH
* get_cursor_pos [6n
* restore_cursor_pos 8
*/
const char req[] = "\0337\033[r\033[999;999H\033[6n";
FILE *fp = fopen("/dev/stdin", "r+");
int f = fileno(fp);
Umm, this code is rather silly, and depends on /proc. Why not use
/dev/tty or if you really mean stdin, use fdopen(0)...?
STDIN_FILENO sounds like a better idea, yes.
Post by Rich Felker
struct winsize w = {0,0,0,0};
int ret;
struct termios new;
tcgetattr(0, &old); /* fiddle echo */
new = old;
new.c_cflag |= (CLOCAL | CREAD);
new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
#if defined(TIMEOUT) && (TIMEOUT >=1)
Should add a comment /* TIMEOUT in deciseconds */ and should default to
9 or the like..
Post by Rich Felker
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = TIMEOUT;
#endif
tcsetattr(0, TCSANOW, &new);
atexit(reset_to_old);
Using atexit() is not useful unless you call exit() from somewhere in
hmz. didn't i exit(ret)? no, i didn't. The whole alarm() can be canned
(i think) if TIMEOUT is used, perhaps. Didn't look closely.
Post by Rich Felker
the program. Default fatal signal handlers cannot call atexit handlers
for you because they take place at the kernel level so you need to
handle them yourself if you want to.
Keep in mind that for static linking, atexit could add a lot of size
to the program too. So can scanf/printf. The program hardly uses stdio
as written and it should be easy to make it not depend on stdio at
all..
Well, but how would you output ROWS = \n COLUMNS = without outputting
anything?

That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)

I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Rich Felker
2006-09-21 18:04:13 UTC
Permalink
Post by Bernhard Fischer
Post by Rich Felker
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = TIMEOUT;
#endif
tcsetattr(0, TCSANOW, &new);
atexit(reset_to_old);
Using atexit() is not useful unless you call exit() from somewhere in
hmz. didn't i exit(ret)? no, i didn't. The whole alarm() can be canned
(i think) if TIMEOUT is used, perhaps. Didn't look closely.
Returning from main is an implicit exit so that's ok; my point was
that the atexit code will not automatically get called when you
receive a fatal signal. If you want to cleanup after fatal signals you
need to trap them.
Post by Bernhard Fischer
Post by Rich Felker
the program. Default fatal signal handlers cannot call atexit handlers
for you because they take place at the kernel level so you need to
handle them yourself if you want to.
Keep in mind that for static linking, atexit could add a lot of size
to the program too. So can scanf/printf. The program hardly uses stdio
as written and it should be easy to make it not depend on stdio at
all..
Well, but how would you output ROWS = \n COLUMNS = without outputting
anything?
IMO (and I seem recall someone else in the thread saying the same)
setting the variables is not a good idea anyway, so it's probably not
useful to print these.
Post by Bernhard Fischer
That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)
I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Yeah somewhere like that, I suppose. And if it's going in BB there's
no problem with using stdio, etc. since they'll already be linked
anyway. Avoiding them is only useful for tiny standalone programs.

Rich
Bernhard Fischer
2006-09-21 20:17:44 UTC
Permalink
Post by Rich Felker
IMO (and I seem recall someone else in the thread saying the same)
setting the variables is not a good idea anyway, so it's probably not
useful to print these.
Post by Bernhard Fischer
That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)
I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Yeah somewhere like that, I suppose. And if it's going in BB there's
no problem with using stdio, etc. since they'll already be linked
anyway. Avoiding them is only useful for tiny standalone programs.
The attached should actually work for settion the w/h.
Dave, can you test this please?

Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?

stats:
(with IMA mode, bloatcheck):
function old new delta
resize_main - 220 +220
.rodata 174048 174096 +48
static.check_mntent_file 760 776 +16
static.e2fsck_pass1 7804 7816 +12
evaltreenr 623 633 +10
evaltree 623 633 +10
static.add_interface 300 302 +2
static.qrealloc 45 44 -1
static.glob3 37 35 -2
busybox_main 472 470 -2
static.popstring 150 147 -3
static.parse_opts 61 56 -5
static.diffreg 2945 2938 -7
static.new_init_module 505 497 -8
ext2fs_open_inode_scan 403 391 -12
ed_main 3348 3323 -25
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 6/9 up/down: 318/-65) Total: 253 bytes

(IMA, size)
$ size busybox_old busybox
text data bss dec hex filename
823938 6436 239444 1069818 1052fa busybox_old
824224 6440 239444 1070108 10541c busybox


(legacy, size)
$ size console-tools/resize.o
text data bss dec hex filename
254 0 0 254 fe console-tools/resize.o

-------------- next part --------------
Index: console-tools/Config.in
===================================================================
--- console-tools/Config.in (revision 16161)
+++ console-tools/Config.in (working copy)
@@ -58,6 +58,13 @@ config CONFIG_RESET
This program is used to reset the terminal screen, if it
gets messed up.

+config CONFIG_RESIZE
+ bool "resize"
+ default n
+ help
+ This program is used to (re)set the width and height of your current
+ terminal.
+
config CONFIG_SETCONSOLE
bool "setconsole"
default n
Index: console-tools/Makefile.in
===================================================================
--- console-tools/Makefile.in (revision 16161)
+++ console-tools/Makefile.in (working copy)
@@ -20,6 +20,7 @@ CONSOLETOOLS-$(CONFIG_LOADFONT) += loadf
CONSOLETOOLS-$(CONFIG_LOADKMAP) += loadkmap.o
CONSOLETOOLS-$(CONFIG_OPENVT) += openvt.o
CONSOLETOOLS-$(CONFIG_RESET) += reset.o
+CONSOLETOOLS-$(CONFIG_RESIZE) += resize.o
CONSOLETOOLS-$(CONFIG_SETKEYCODES) += setkeycodes.o
CONSOLETOOLS-$(CONFIG_SETLOGCONS) += setlogcons.o

Index: console-tools/resize.c
===================================================================
--- console-tools/resize.c (revision 0)
+++ console-tools/resize.c (revision 0)
@@ -0,0 +1,40 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * resize - set terminal width and height.
+ *
+ * Copyright 2006 Bernhard Fischer
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details.
+ */
+/* no options, no getopt */
+#include "busybox.h"
+
+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {
+ /* save_cursor_pos 7
+ * scroll_whole_screen [r
+ * put_cursor_waaaay_off [$x;$yH
+ * get_cursor_pos [6n
+ * restore_cursor_pos 8
+ */
+ const char req[] = "\0337\033[r\033[999;999H\033[6n";
+ int f = STDIN_FILENO;
+ struct winsize w = {0,0,0,0};
+ int ret;
+ struct termios old, new;
+ tcgetattr(STDIN_FILENO, &old); /* fiddle echo */
+ new = old;
+ new.c_cflag |= (CLOCAL | CREAD);
+ new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+ new.c_cc[VMIN] = 0;
+ new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif
+ tcsetattr(STDIN_FILENO, TCSANOW, &new);
+ write(f, req, sizeof req);
+ scanf("\033[%hu;%huR", &w.ws_row, &w.ws_col);
+ ret = ioctl(STDIN_FILENO, TIOCSWINSZ, &w);
+ write(f, "\0338", 2);
+ tcsetattr(STDIN_FILENO, TCSANOW, &old);
+ return ret;
+}
Index: include/libbb.h
===================================================================
--- include/libbb.h (revision 16161)
+++ include/libbb.h (working copy)
@@ -231,8 +231,9 @@ extern void trim(char *s);
extern char *skip_whitespace(const char *);

#ifndef BUILD_INDIVIDUAL
-extern struct BB_applet *find_applet_by_name(const char *name);
-void run_applet_by_name(const char *name, int argc, char **argv);
+extern struct BB_applet *find_applet_by_name(const char *name)
+ USE_FEATURE_SH_STANDALONE_SHELL(ATTRIBUTE_EXTERNALLY_VISIBLE);
+extern void run_applet_by_name(const char *name, int argc, char **argv);
#endif

/* dmalloc will redefine these to it's own implementation. It is safe
Index: include/usage.h
===================================================================
--- include/usage.h (revision 16163)
+++ include/usage.h (working copy)
@@ -2455,6 +2455,11 @@ USE_FEATURE_MDEV_CONFIG( \
#define reset_full_usage \
"Resets the screen."

+#define resize_trivial_usage \
+ ""
+#define resize_full_usage \
+ "Resizes the screen."
+
#define rm_trivial_usage \
"[OPTION]... FILE..."
#define rm_full_usage \
Index: include/applets.h
===================================================================
--- include/applets.h (revision 16161)
+++ include/applets.h (working copy)
@@ -226,6 +226,7 @@ USE_REALPATH(APPLET(realpath, _BB_DIR_US
USE_HALT(APPLET_ODDNAME(reboot, halt, _BB_DIR_SBIN, _BB_SUID_NEVER, reboot))
USE_RENICE(APPLET(renice, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RESET(APPLET(reset, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_RESIZE(APPLET(resize, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RM(APPLET(rm, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMDIR(APPLET(rmdir, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMMOD(APPLET(rmmod, _BB_DIR_SBIN, _BB_SUID_NEVER))
Bernhard Fischer
2006-09-21 21:04:54 UTC
Permalink
Post by Bernhard Fischer
Post by Rich Felker
IMO (and I seem recall someone else in the thread saying the same)
setting the variables is not a good idea anyway, so it's probably not
useful to print these.
Post by Bernhard Fischer
That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)
I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Yeah somewhere like that, I suppose. And if it's going in BB there's
no problem with using stdio, etc. since they'll already be linked
anyway. Avoiding them is only useful for tiny standalone programs.
The attached should actually work for settion the w/h.
Dave, can you test this please?
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
function old new delta
resize_main - 220 +220
.rodata 174048 174096 +48
static.check_mntent_file 760 776 +16
static.e2fsck_pass1 7804 7816 +12
evaltreenr 623 633 +10
evaltree 623 633 +10
static.add_interface 300 302 +2
static.qrealloc 45 44 -1
static.glob3 37 35 -2
busybox_main 472 470 -2
static.popstring 150 147 -3
static.parse_opts 61 56 -5
static.diffreg 2945 2938 -7
static.new_init_module 505 497 -8
ext2fs_open_inode_scan 403 391 -12
ed_main 3348 3323 -25
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 6/9 up/down: 318/-65) Total: 253 bytes
(IMA, size)
$ size busybox_old busybox
text data bss dec hex filename
823938 6436 239444 1069818 1052fa busybox_old
824224 6440 239444 1070108 10541c busybox
(legacy, size)
$ size console-tools/resize.o
text data bss dec hex filename
254 0 0 254 fe console-tools/resize.o
And without being actively stoopid:
text data bss dec hex filename
223 0 0 223 df console-tools/resize.o

-------------- next part --------------
Index: console-tools/Makefile.in
===================================================================
--- console-tools/Makefile.in (revision 16161)
+++ console-tools/Makefile.in (working copy)
@@ -20,6 +20,7 @@ CONSOLETOOLS-$(CONFIG_LOADFONT) += loadf
CONSOLETOOLS-$(CONFIG_LOADKMAP) += loadkmap.o
CONSOLETOOLS-$(CONFIG_OPENVT) += openvt.o
CONSOLETOOLS-$(CONFIG_RESET) += reset.o
+CONSOLETOOLS-$(CONFIG_RESIZE) += resize.o
CONSOLETOOLS-$(CONFIG_SETKEYCODES) += setkeycodes.o
CONSOLETOOLS-$(CONFIG_SETLOGCONS) += setlogcons.o

Index: console-tools/resize.c
===================================================================
--- console-tools/resize.c (revision 0)
+++ console-tools/resize.c (revision 0)
@@ -0,0 +1,41 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * resize - set terminal width and height.
+ *
+ * Copyright 2006 Bernhard Fischer
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details.
+ */
+/* no options, no getopt */
+#include "busybox.h"
+
+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {
+ /* save_cursor_pos 7
+ * scroll_whole_screen [r
+ * put_cursor_waaaay_off [$x;$yH
+ * get_cursor_pos [6n
+ * restore_cursor_pos 8
+ */
+ struct winsize w = {0,0,0,0};
+ int ret;
+ struct termios old, new;
+ tcgetattr(STDOUT_FILENO, &old); /* fiddle echo */
+ new = old;
+ new.c_cflag |= (CLOCAL | CREAD);
+ new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+ new.c_cc[VMIN] = 0;
+ new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif
+ tcsetattr(STDOUT_FILENO, TCSANOW, &new);
+ printf("\0337\033[r\033[999;999H\033[6n");
+ scanf("\033[%hu;%huR", &w.ws_row, &w.ws_col);
+ ret = ioctl(STDOUT_FILENO, TIOCSWINSZ, &w);
+ printf("\0338");
+ tcsetattr(STDOUT_FILENO, TCSANOW, &old);
+ if (00 && argc > 1)
+ printf("COLUMNS=%d;LINES=%d;export COLUMNS LINES;",
+ w.ws_col, w.ws_row);
+ return ret;
+}
Index: console-tools/Config.in
===================================================================
--- console-tools/Config.in (revision 16161)
+++ console-tools/Config.in (working copy)
@@ -58,6 +58,13 @@ config CONFIG_RESET
This program is used to reset the terminal screen, if it
gets messed up.

+config CONFIG_RESIZE
+ bool "resize"
+ default n
+ help
+ This program is used to (re)set the width and height of your current
+ terminal.
+
config CONFIG_SETCONSOLE
bool "setconsole"
default n
Index: include/libbb.h
===================================================================
--- include/libbb.h (revision 16161)
+++ include/libbb.h (working copy)
@@ -231,8 +231,9 @@ extern void trim(char *s);
extern char *skip_whitespace(const char *);

#ifndef BUILD_INDIVIDUAL
-extern struct BB_applet *find_applet_by_name(const char *name);
-void run_applet_by_name(const char *name, int argc, char **argv);
+extern struct BB_applet *find_applet_by_name(const char *name)
+ USE_FEATURE_SH_STANDALONE_SHELL(ATTRIBUTE_EXTERNALLY_VISIBLE);
+extern void run_applet_by_name(const char *name, int argc, char **argv);
#endif

/* dmalloc will redefine these to it's own implementation. It is safe
Index: include/usage.h
===================================================================
--- include/usage.h (revision 16163)
+++ include/usage.h (working copy)
@@ -2455,6 +2455,11 @@ USE_FEATURE_MDEV_CONFIG( \
#define reset_full_usage \
"Resets the screen."

+#define resize_trivial_usage \
+ ""
+#define resize_full_usage \
+ "Resizes the screen."
+
#define rm_trivial_usage \
"[OPTION]... FILE..."
#define rm_full_usage \
Index: include/applets.h
===================================================================
--- include/applets.h (revision 16161)
+++ include/applets.h (working copy)
@@ -226,6 +226,7 @@ USE_REALPATH(APPLET(realpath, _BB_DIR_US
USE_HALT(APPLET_ODDNAME(reboot, halt, _BB_DIR_SBIN, _BB_SUID_NEVER, reboot))
USE_RENICE(APPLET(renice, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RESET(APPLET(reset, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_RESIZE(APPLET(resize, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RM(APPLET(rm, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMDIR(APPLET(rmdir, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMMOD(APPLET(rmmod, _BB_DIR_SBIN, _BB_SUID_NEVER))
Tito
2006-09-21 21:26:44 UTC
Permalink
On Thursday 21 September 2006 23:04, Bernhard Fischer wrote:

snip
Post by Bernhard Fischer
text data bss dec hex filename
223 0 0 223 df console-tools/resize.o
Hi,

+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+???????new.c_cc[VMIN] = 0;
+???????new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif

Just out of curiosity, why do you use all this defines if

#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */

is always defined, wouldn't it be cleaner:

new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = 100; /* Timeout in deciseconds */


And, what is this for?

???????if (00 && argc > 1)
???????????????printf("COLUMNS=%d;LINES=%d;export COLUMNS LINES;",
???????????????????????w.ws_col, w.ws_row);

What is 00?
Why you are testing for argc > 1 when you previously declared:

int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv)

Maybe I'm not smart enough to understand this magics.....

Ciao,
Tito
Bernhard Fischer
2006-09-21 21:45:23 UTC
Permalink
Post by Bernhard Fischer
snip
Post by Bernhard Fischer
text data bss dec hex filename
223 0 0 223 df console-tools/resize.o
Hi,
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+???????new.c_cc[VMIN] = 0;
+???????new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif
Just out of curiosity, why do you use all this defines if
#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = 100; /* Timeout in deciseconds */
And, what is this for?
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.

pgf said that the thing he looked at had a 10 second delay, and that's
just a trivial way to make it configurable without mocking much with the
source later on. It can certainly be dropped and hardcoded, yes.
Post by Bernhard Fischer
???????if (00 && argc > 1)
???????????????printf("COLUMNS=%d;LINES=%d;export COLUMNS LINES;",
???????????????????????w.ws_col, w.ws_row);
What is 00?
0

It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.

Since i deny the need for adding several newlines (three) for no good
reason, i provided the string that i would like to see there that has
the same effect like the bloated version but is smaller.
Post by Bernhard Fischer
int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv)
Maybe I'm not smart enough to understand this magics.....
ATTRIBUTE_UNUSED just sets TREE_NO_WARNING (or however it's spelled) so
you don't get warnings about unused parameters. Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.

Easy to fix (i have a patch here at home which did this, against an
ancient version) but i'm not convinced if Rob likes this or not as it
would make the applet dispatch-table filler macros even less
comprehensible.

Rob?
Mind if Tito or i do this, mid-term?
Rob Landley
2006-09-22 03:25:04 UTC
Permalink
Post by Bernhard Fischer
Post by Tito
And, what is this for?
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations that are too trivial to bother
most people with. It's the next step up from going in and twiddling the
source code yourself.
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.

Ok, preserving the behavior of that strikes me as a good thing. I guess that
means I should take another look at the patch...

+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)

What on _earth_?

+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {

The curly bracket goes on the start of the next line.

Have we been using ATTRIBUTE_UNUSED on argc and argv anywhere else? Is this
really needed? We've never appled ATTRIBUTE_UNUSED to argc and argv that I'm
aware of. If coreutils/sync.c hasn't been using this (ever), and no I'm not
recommending adding it. Why is that there?
Post by Bernhard Fischer
ATTRIBUTE_UNUSED just sets TREE_NO_WARNING (or however it's spelled) so
you don't get warnings about unused parameters.
I am already not getting warnings about unused parameters. Why are you
getting them?
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
I've been pondering switching argv and argc to globals for most of a year (I
suggested it on the list before), but lemme get bbsh into reasonable shape
first.
Post by Bernhard Fischer
Easy to fix (i have a patch here at home which did this, against an
ancient version) but i'm not convinced if Rob likes this or not as it
would make the applet dispatch-table filler macros even less
comprehensible.
Rob?
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-22 07:27:47 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
I've been pondering switching argv and argc to globals for most of a year (I
suggested it on the list before), but lemme get bbsh into reasonable shape
And i implemented and sent the patch to the list before.
See
http://www.busybox.net/lists/busybox/2006-July/023016.html

Made the binary bigger (for me)..
Rob Landley
2006-09-22 20:13:15 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
I've been pondering switching argv and argc to globals for most of a year (I
suggested it on the list before), but lemme get bbsh into reasonable shape
And i implemented and sent the patch to the list before.
See
http://www.busybox.net/lists/busybox/2006-July/023016.html
Made the binary bigger (for me)..
I'm trying to track down why, but applying your old patch to an anonymous
checkout of svn 15566 (which the patch seems to say it applies against)
produced lots of failures.

Any idea what I'm doing wrong?

svn co svn://busybox.net/trunk/busybox -r 15566
cd busybox
patch -p0 -i ../bb.argc.00g.diff

Wrong version?

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-22 20:13:15 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
I've been pondering switching argv and argc to globals for most of a year (I
suggested it on the list before), but lemme get bbsh into reasonable shape
And i implemented and sent the patch to the list before.
See
http://www.busybox.net/lists/busybox/2006-July/023016.html
Made the binary bigger (for me)..
I'm trying to track down why, but applying your old patch to an anonymous
checkout of svn 15566 (which the patch seems to say it applies against)
produced lots of failures.

Any idea what I'm doing wrong?

svn co svn://busybox.net/trunk/busybox -r 15566
cd busybox
patch -p0 -i ../bb.argc.00g.diff

Wrong version?

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-22 07:44:32 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
[snip global argv]
Post by Rob Landley
Post by Bernhard Fischer
Easy to fix (i have a patch here at home which did this, against an
ancient version) but i'm not convinced if Rob likes this or not as it
would make the applet dispatch-table filler macros even less
comprehensible.
Rob?
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?
provide means to let applets be of the form

variant_A_main(void)
variant_B_main(int argc)
variant_C_main(char **argv)
variant_D_main(int argc, char **argv)

by making the PROTOTYPES peruse
#define _BB_NOARG (void)
#define _BB_ARGC (int argc)
#define _BB_ARGV (char **argv)
#define _BB_ARGS (int argc, char **argv)

via


Index: include/applets.h
===================================================================
--- include/applets.h (revision 16172)
+++ include/applets.h (working copy)
@@ -15,11 +15,15 @@
#undef APPLET_ODDNAME
#undef APPLET_NOUSAGE

+#define _BB_NOARG (void)
+#define _BB_ARGC (int argc)
+#define _BB_ARGV (char **argv)
+#define _BB_ARGS (int argc, char **argv)

#if defined(PROTOTYPES)
-# define APPLET(a,b,c) extern int a##_main(int argc, char **argv);
-# define APPLET_NOUSAGE(a,b,c,d) extern int b##_main(int argc, char
**argv);
-# define APPLET_ODDNAME(a,b,c,d,e) extern int b##_main(int argc, char
**argv);
+# define APPLET(a,b,c) extern int a##_main ## c;
+# define APPLET_NOUSAGE(a,b,c,d) extern int b##_main ## c;
+# define APPLET_ODDNAME(a,b,c,d,e) extern int b##_main ## c;
#elif defined(MAKE_USAGE)
# ifdef CONFIG_FEATURE_VERBOSE_USAGE
# define APPLET(a,b,c) a##_trivial_usage "\n\n" a##_full_usage "\0"


so you can say (e.g. for test):

@@ -47,7 +51,7 @@
#endif


-USE_TEST(APPLET_NOUSAGE([, test, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_TEST(APPLET_NOUSAGE([, test, _BB_ARGS, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_TEST(APPLET_NOUSAGE([[, test, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_ADDGROUP(APPLET(addgroup, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_ADDUSER(APPLET(adduser, _BB_DIR_BIN, _BB_SUID_NEVER))
Rob Landley
2006-09-22 18:24:47 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?
provide means to let applets be of the form
variant_A_main(void)
variant_B_main(int argc)
variant_C_main(char **argv)
variant_D_main(int argc, char **argv)
by making the PROTOTYPES peruse
#define _BB_NOARG (void)
#define _BB_ARGC (int argc)
#define _BB_ARGV (char **argv)
#define _BB_ARGS (int argc, char **argv)
Oh please no.

Lemme look at why the global version got bigger...

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-24 09:12:24 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?
provide means to let applets be of the form
variant_A_main(void)
variant_B_main(int argc)
variant_C_main(char **argv)
variant_D_main(int argc, char **argv)
by making the PROTOTYPES peruse
#define _BB_NOARG (void)
#define _BB_ARGC (int argc)
#define _BB_ARGV (char **argv)
#define _BB_ARGS (int argc, char **argv)
Oh please no.
Lemme look at why the global version got bigger...
sure.
Bernhard Fischer
2006-09-24 09:12:24 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?
provide means to let applets be of the form
variant_A_main(void)
variant_B_main(int argc)
variant_C_main(char **argv)
variant_D_main(int argc, char **argv)
by making the PROTOTYPES peruse
#define _BB_NOARG (void)
#define _BB_ARGC (int argc)
#define _BB_ARGV (char **argv)
#define _BB_ARGS (int argc, char **argv)
Oh please no.
Lemme look at why the global version got bigger...
sure.
Rob Landley
2006-09-22 18:24:47 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?
provide means to let applets be of the form
variant_A_main(void)
variant_B_main(int argc)
variant_C_main(char **argv)
variant_D_main(int argc, char **argv)
by making the PROTOTYPES peruse
#define _BB_NOARG (void)
#define _BB_ARGC (int argc)
#define _BB_ARGV (char **argv)
#define _BB_ARGS (int argc, char **argv)
Oh please no.

Lemme look at why the global version got bigger...

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-22 08:25:10 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.
Ok, preserving the behavior of that strikes me as a good thing. I guess that
I've applied it as r16176 for now.
Feel free to wipe it out of the tree like you did with taskset, if you
feel like.
Post by Rob Landley
means I should take another look at the patch...
+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
What on _earth_?
The version i checked in doesn't set a timeout. It can easily be fixed
later on, if needed (i wouldn't be surprised if a timeout handling is
needed in the wild).
Post by Rob Landley
+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {
The curly bracket goes on the start of the next line.
done.
Post by Rob Landley
I am already not getting warnings about unused parameters. Why are you
getting them?
because i asked to get them since they remind me that it's a todo (for
me, at least) ;)

cheers,
Bernhard
Rob Landley
2006-09-22 18:54:11 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.
Ok, preserving the behavior of that strikes me as a good thing. I guess that
I've applied it as r16176 for now.
Feel free to wipe it out of the tree like you did with taskset, if you
feel like.
Done.

"I'll think about it" != "Ooh, that means I should apply it". It means I need
to think about how best to do this.

The purpose of this applet is to run from the command line? Or are we
encouraging people to have it in their /etc/profile? If they start typing
before their /etc/profile runs (or they "echo command | sh", don't we have
the same problem with bbsh interactive mode, where it shouldn't do this if
there's already data waiting on stdin? (Or should it discard any data
waiting on stdin?)

And _if_ we do this, I'd like to re-use the code that bbsh is using to do this
probing for interactive mode, rather than having two implementations in the
tree. I believe I _said_ that.

Also, I'd rather not add new code into the tree with "or later" and then have
to go back and remove it as I get around to making the license notices
uniform.
Post by Bernhard Fischer
Post by Rob Landley
I am already not getting warnings about unused parameters. Why are you
getting them?
because i asked to get them since they remind me that it's a todo (for
me, at least) ;)
Why? What's the point? You ask the compiler to give you a warning and then
you tell the compiler not to give you that warning _here_. Why do this
thing? There are often good reasons for unused function parameters. There
are never good reasons for unused local variables.

I really don't want to fill the tree with "humor the compiler's warning
generator" markup. I repeat, I don't ask the compiler to give me warnings
that it's not capable of generating competently.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-24 09:30:21 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.
Ok, preserving the behavior of that strikes me as a good thing. I guess
that
Post by Bernhard Fischer
I've applied it as r16176 for now.
Feel free to wipe it out of the tree like you did with taskset, if you
feel like.
Done.
Thanks so much.
Post by Rob Landley
"I'll think about it" != "Ooh, that means I should apply it". It means I need
to think about how best to do this.
The purpose of this applet is to run from the command line? Or are we
It's purpose is to be run interactively (only, i'd say).
Post by Rob Landley
encouraging people to have it in their /etc/profile? If they start typing
before their /etc/profile runs (or they "echo command | sh", don't we have
the same problem with bbsh interactive mode, where it shouldn't do this if
there's already data waiting on stdin? (Or should it discard any data
waiting on stdin?)
I don't understand what you're saying here. Please explain?
Post by Rob Landley
And _if_ we do this, I'd like to re-use the code that bbsh is using to do this
probing for interactive mode, rather than having two implementations in the
tree. I believe I _said_ that.
bbsh doesn't have that code AFAICS.
You don't seem to want to collaborate with anybody wrt bbsh. That
resize applet serves a unique, established purpose that shouldn't be
hindered by eventual progress you as a single person achieve with bringing
bbsh forward.
Post by Rob Landley
Also, I'd rather not add new code into the tree with "or later" and then have
to go back and remove it as I get around to making the license notices
uniform.
I would have removed the or later in a day or two, if the applet was
still in the tree
Rob Landley
2006-09-25 01:24:28 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
The purpose of this applet is to run from the command line? Or are we
It's purpose is to be run interactively (only, i'd say).
Post by Rob Landley
encouraging people to have it in their /etc/profile? If they start typing
before their /etc/profile runs (or they "echo command | sh", don't we have
the same problem with bbsh interactive mode, where it shouldn't do this if
there's already data waiting on stdin? (Or should it discard any data
waiting on stdin?)
I don't understand what you're saying here. Please explain?
People who are going to be running a serial console a lot are going to be
tempted to stick this in the /etc/profile or ~/.shellrc or some such, so that
the shell they run on the serial console gets set up correctly automatically.

We have two ways of dealing with this:

1) Put a big warning sign in its docs, ala "This uses in-band signalling, so
typing anything between the time you run it and the time it returns could
interfere with it functioning, and putting it in /etc/profile could have
nasty side effects." This wouldn't actually help matters because nobody ever
reads the docs, but it would give us something to point at and feel smug
about when people come to the list for help.

2) Try to make it work when it gets run from ".shellrc".

Nontrivial, but possible. At least it's possible to guard against it doing
_stupid_ things, unfortunately by making it fail easily.

My first instinct was to wire it into the darn shell (since we already have a
set of tests for "interactive mode" anyway, which are about 2/3 of the tests
we'd need to do this safely). But if there's an applet that already does
this, I want to also implement that applet as well, which means I need to
stick this functinality in libbb.

I've got a number of unanswered questions. For example, when this fails
(reads garbage, perhaps) should it print a warning similar to the
existing "Job control turned off" warning? ("Terminal probing failed,
run 'resize' to try again." except that's darn verbose and a waste of bytes.
Sigh...)

How much of the "interactive mode" tests should move from bbsh into the
libbb/resize_probe_thing()? (For example: don't do this if stdin and stdout
don't point to the same device, but does that device have to be a _terminal_?

I agree that 10 seconds is too long of a timeout (enough to annoy humans).
I'm thinking 2 is probably plenty, maybe 3 for paranoia, but if your xterm
gets swapped to disk to swapped to disk I'm ok with this failing (see
possible warning message, above).

I'm 90% certain that this should stay separate from
get_terminal_width_height(), but it's darn tempting to at least put them next
to each other.

Did I mention I spent a decent chunk of the week before Bruce cropped up
researching terminal control stuff? (I now have a tentative understanding of
the difference between sessions and process groups. Yes, I believe I now
understand how to make getpid(), setsid(), setpgid(), and tcsetpgrp() play
nice with each other in the context of vfork() resetting signal handlers
before calling exec()! In that context, using the ansi probe as a fallback
for a zero by zero terminal makes perfect sense to me, which probably means
it drove me insane learning it...

And then Bruce showed up and the stress turned my brain to jello. Don't ask
me how "The issue is resolved now!" turned into a teleconference with me,
Bruce, Erik, and the SFLC monday evening. Attracting Bruce's attention is
like getting a terminal disease, it's never _cured_ you just go into
_remission_ for a while. However, the alternatives are "see this through
until one of us dies of old age, and I'm younger than he is" or "Walk away
from BusyBox entirely". And I've put years into BusyBox and accepted a lot
of responsibility for it which I take quite seriously.

To be clear, "Bruce getting his way" and "Me walking away from the current
codebase" are equivalent options. If he somehow managed to prove that I
couldn't put out GPLv2 only versions of the project (which he can't), I would
stop working on the current code base completely. Probably I'd start a new
one from scratch. It would actually only take me about a year to reimplement
the 2/3 of it I actually use.

In the meantime, lots of naps and long soothing walks, to make at least _some_
off the headaches go away...
Post by Bernhard Fischer
Post by Rob Landley
And _if_ we do this, I'd like to re-use the code that bbsh is using to do this
probing for interactive mode, rather than having two implementations in the
tree. I believe I _said_ that.
bbsh doesn't have that code AFAICS.
The copy that's currently in the tree doesn't, no. But:

http://busybox.net/lists/busybox/2006-September/024571.html

My current version's gone all complicated again because I tried to add
terminal control, pipe/redirect support, and quote parsing all at once and it
got snarled up. (Sigh. Trying to code while stressed out of my mind by
Bruce eruptions isn't helping, either. And I feel guilty for not keeping up
with the review of Denis's patches either: there are three things I strongly
suspect he's broken and haven't gone and tested because then I'd have to fix
them. This is the first time all weekend I've gotten an uninterrupted hour
and a half to sit down and code, and I've gotten _three_ phone calls during
it already.)

I'm pondering breaking one of the three out and patching it onto the in-tree
version just to flush some of the complexity. Terminal control is the
obvious candidate there.
Post by Bernhard Fischer
You don't seem to want to collaborate with anybody wrt bbsh.
It's not quite that simple. I have put in a _lot_ of prep work for bbsh. You
can too if you'd like, but it took _me_ most of a year. In order to get
ready to do bbsh, I have so far read:

1) The lash.c code (I printed it out and read it all, beginning to end, at
least three times; I've carried around a copy in my backpack for months now).
Pay special attention to the things it does wrong, such as:

landley at driftwood:~/busybox/busybox$ touch "one two"
landley at driftwood:~/busybox/busybox$ ./busybox lash
~/busybox/busybox $ ls one*
ls: one: No such file or directory
ls: two: No such file or directory

2) Skim the hush and msh code. Don't have to be too thorough about it, just
figure out approximately what features they've got.

3) Read the SUSv3 shell language specification. (Again, printing out a copy
and carrying it around everywhere you go for weeks seems to help, and I'm not
all the way through it yet, I go through two pages and then have to stop and
think for half an hour, and then write down strange notes about the
ramifications, such as the fact that "echo -ne 'false &\\\n&echo hello' | sh"
has to become "false && echo hello" and so shouldn't print anything because
the \ eats the newline _first_ and the && token is parsed _afterwards_ and
yes I have to test for that. Oh, and you can't just look for \ at the end of
the line before parsing your way up to that: try "ls -l # \". Parsing is
very context-sensitive and only makes sense front to back...)

You might also want to look at the SUSv3 shell command definition, which is
not the same thing as the language specification.

4) Read the bash man page. (Print it out and add it to the big three ring
binder you carry around with you. I'm still only at the "selected bits of it
made sense" stage. Also the bash FAQ and the advanced bash programming
guide, although that adds another 300+ pages and I haven't printed 'em out
yet because I'd need another ream of paper and a second binder. But I've got
the pdfs on my laptop.)

5) Read about the historical bourne, korn, and c shells. (I hate to recommend
the wikipedia articles, but it's a start and they link to other stuff. "csh
programming considered harmful" has a few interesting bits.)

6) Ponder the really weird corner cases of parsing, like embedded nul bytes in
the output of backquote commands. Check to see what bash does. Take more
notes. (Pop quiz: why is having two spaces between "one" and "two" in
echo "$(echo "one two")"
a much better test then just having one space there?)

7) Break the whole mess down into functional sub-units like job control and
terminal control, and then ponder each of _their_ weird corner cases, like
what happens when you type "read i" on the command line and hit ctrl-z?
Notice that the read command is like cd and exit: it can't be a background
process because the point of the thing is to set an environment variable, and
that environment variable would go away when the background process did.
(Other fun things to try ctrl-z with include "sleep 5 && ls | sort", "sleep
5 ; ls | sort", and of course "sleep 5 | wc". Then go back through the specs
and figure out how much of that behavior is actually _required_, and how much
is an implementation idiosyncrasy. That's still a todo item of mine.)

8) Work out how the functional sub-units interact with each other. Can quote
parsing and pipes/redirects be separated so you can arbitrarily disable one
but not the other? What features require a union of otherwise orthogonal
functional groups? (Look at ctrl-z: You need both job control and terminal
control for that, but job control and terminal control shouldn't depend on
each other because you can detach processes with & in a shell script and you
should be able to kill things with ctrl-c even when you can't background
them.)

According to http://busybox.net/~landley/notes.html my first "hello world"
version of bbsh was November 7, 2005, but that wasn't when I started on it.
I'd been studying what was required for a while. The October 14 entry
mentions my intention to do it, but I'd been poking at it before then. The
reason for the big gap between last November and when I put the "tiniest
possible shell I can do" into the tree was that my early attempts at this
only proved to me how little I knew about the problem space, and I had to go
study lots and lots and lots.

We have four shells in the tree right now. "Doing a shell" is not a major
limiting factor. I want to do it _right_, so we can have _fewer_ shells..
Post by Bernhard Fischer
That
resize applet serves a unique, established purpose that shouldn't be
hindered by eventual progress you as a single person achieve with bringing
bbsh forward.
If we're going to have it in the tree, we should do it right.

And I'd already added equivalent functionality to bbsh (remember how I worked
out a functional probe string without actually seeing the other code), and
when I found out that resize was an existing applet I wanted to generalize
that code.

I also don't know why the resize applet you submitted was resetting terminal
parameters _before_ doing the probing.
Post by Bernhard Fischer
Post by Rob Landley
Also, I'd rather not add new code into the tree with "or later" and then have
to go back and remove it as I get around to making the license notices
uniform.
I would have removed the or later in a day or two, if the applet was
still in the tree
I meant to put the darn thing back into the tree yesterday, but the SFLC
scheduled a teleconference they want both me and Bruce on, and I got another
headache and had to go lie down. (I'll be _so_ happy when Bruce finally goes
back to his crypt. This is _not_ good for my health.)

Then this morning my laptop decided to do a fresh reboot rather than
resume-from-suspend, so I lost my open window and have to track down the
patch again. (Software suspend on Ubuntu 6.06 is _really_ flaky. I think
the problem is that my laptop's hard drive has an onboard buffer that only
sometimes flushes the last block before the power goes off, and when it
doesn't the swap partition has all the resume data in it but doesn't have the
start of the partition marked as a suspend image instead of normal swap. I'd
blame the hardware, except that earlier versions of ubuntu didn't do this
(they had _different_ bugs). I think it's actually the kernel missing a
flush somewhere in the suspend to disk path.)

No, I haven't built my own kernel for my laptop. Last time I tried it,
getting the ipw2200 firmware loading to line up again was enough of a pain I
gave up, and I've been way too busy to get back to it...

But mostly? Weekend. Tired. Sleeping muchly, visiting Ikea, reading... ok,
reading the OLS2006 proceedings but _also_ reading a fluffy Wen Spencer book
about elves and dragons and such.

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-25 01:24:28 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
The purpose of this applet is to run from the command line? Or are we
It's purpose is to be run interactively (only, i'd say).
Post by Rob Landley
encouraging people to have it in their /etc/profile? If they start typing
before their /etc/profile runs (or they "echo command | sh", don't we have
the same problem with bbsh interactive mode, where it shouldn't do this if
there's already data waiting on stdin? (Or should it discard any data
waiting on stdin?)
I don't understand what you're saying here. Please explain?
People who are going to be running a serial console a lot are going to be
tempted to stick this in the /etc/profile or ~/.shellrc or some such, so that
the shell they run on the serial console gets set up correctly automatically.

We have two ways of dealing with this:

1) Put a big warning sign in its docs, ala "This uses in-band signalling, so
typing anything between the time you run it and the time it returns could
interfere with it functioning, and putting it in /etc/profile could have
nasty side effects." This wouldn't actually help matters because nobody ever
reads the docs, but it would give us something to point at and feel smug
about when people come to the list for help.

2) Try to make it work when it gets run from ".shellrc".

Nontrivial, but possible. At least it's possible to guard against it doing
_stupid_ things, unfortunately by making it fail easily.

My first instinct was to wire it into the darn shell (since we already have a
set of tests for "interactive mode" anyway, which are about 2/3 of the tests
we'd need to do this safely). But if there's an applet that already does
this, I want to also implement that applet as well, which means I need to
stick this functinality in libbb.

I've got a number of unanswered questions. For example, when this fails
(reads garbage, perhaps) should it print a warning similar to the
existing "Job control turned off" warning? ("Terminal probing failed,
run 'resize' to try again." except that's darn verbose and a waste of bytes.
Sigh...)

How much of the "interactive mode" tests should move from bbsh into the
libbb/resize_probe_thing()? (For example: don't do this if stdin and stdout
don't point to the same device, but does that device have to be a _terminal_?

I agree that 10 seconds is too long of a timeout (enough to annoy humans).
I'm thinking 2 is probably plenty, maybe 3 for paranoia, but if your xterm
gets swapped to disk to swapped to disk I'm ok with this failing (see
possible warning message, above).

I'm 90% certain that this should stay separate from
get_terminal_width_height(), but it's darn tempting to at least put them next
to each other.

Did I mention I spent a decent chunk of the week before Bruce cropped up
researching terminal control stuff? (I now have a tentative understanding of
the difference between sessions and process groups. Yes, I believe I now
understand how to make getpid(), setsid(), setpgid(), and tcsetpgrp() play
nice with each other in the context of vfork() resetting signal handlers
before calling exec()! In that context, using the ansi probe as a fallback
for a zero by zero terminal makes perfect sense to me, which probably means
it drove me insane learning it...

And then Bruce showed up and the stress turned my brain to jello. Don't ask
me how "The issue is resolved now!" turned into a teleconference with me,
Bruce, Erik, and the SFLC monday evening. Attracting Bruce's attention is
like getting a terminal disease, it's never _cured_ you just go into
_remission_ for a while. However, the alternatives are "see this through
until one of us dies of old age, and I'm younger than he is" or "Walk away
from BusyBox entirely". And I've put years into BusyBox and accepted a lot
of responsibility for it which I take quite seriously.

To be clear, "Bruce getting his way" and "Me walking away from the current
codebase" are equivalent options. If he somehow managed to prove that I
couldn't put out GPLv2 only versions of the project (which he can't), I would
stop working on the current code base completely. Probably I'd start a new
one from scratch. It would actually only take me about a year to reimplement
the 2/3 of it I actually use.

In the meantime, lots of naps and long soothing walks, to make at least _some_
off the headaches go away...
Post by Bernhard Fischer
Post by Rob Landley
And _if_ we do this, I'd like to re-use the code that bbsh is using to do this
probing for interactive mode, rather than having two implementations in the
tree. I believe I _said_ that.
bbsh doesn't have that code AFAICS.
The copy that's currently in the tree doesn't, no. But:

http://busybox.net/lists/busybox/2006-September/024571.html

My current version's gone all complicated again because I tried to add
terminal control, pipe/redirect support, and quote parsing all at once and it
got snarled up. (Sigh. Trying to code while stressed out of my mind by
Bruce eruptions isn't helping, either. And I feel guilty for not keeping up
with the review of Denis's patches either: there are three things I strongly
suspect he's broken and haven't gone and tested because then I'd have to fix
them. This is the first time all weekend I've gotten an uninterrupted hour
and a half to sit down and code, and I've gotten _three_ phone calls during
it already.)

I'm pondering breaking one of the three out and patching it onto the in-tree
version just to flush some of the complexity. Terminal control is the
obvious candidate there.
Post by Bernhard Fischer
You don't seem to want to collaborate with anybody wrt bbsh.
It's not quite that simple. I have put in a _lot_ of prep work for bbsh. You
can too if you'd like, but it took _me_ most of a year. In order to get
ready to do bbsh, I have so far read:

1) The lash.c code (I printed it out and read it all, beginning to end, at
least three times; I've carried around a copy in my backpack for months now).
Pay special attention to the things it does wrong, such as:

landley at driftwood:~/busybox/busybox$ touch "one two"
landley at driftwood:~/busybox/busybox$ ./busybox lash
~/busybox/busybox $ ls one*
ls: one: No such file or directory
ls: two: No such file or directory

2) Skim the hush and msh code. Don't have to be too thorough about it, just
figure out approximately what features they've got.

3) Read the SUSv3 shell language specification. (Again, printing out a copy
and carrying it around everywhere you go for weeks seems to help, and I'm not
all the way through it yet, I go through two pages and then have to stop and
think for half an hour, and then write down strange notes about the
ramifications, such as the fact that "echo -ne 'false &\\\n&echo hello' | sh"
has to become "false && echo hello" and so shouldn't print anything because
the \ eats the newline _first_ and the && token is parsed _afterwards_ and
yes I have to test for that. Oh, and you can't just look for \ at the end of
the line before parsing your way up to that: try "ls -l # \". Parsing is
very context-sensitive and only makes sense front to back...)

You might also want to look at the SUSv3 shell command definition, which is
not the same thing as the language specification.

4) Read the bash man page. (Print it out and add it to the big three ring
binder you carry around with you. I'm still only at the "selected bits of it
made sense" stage. Also the bash FAQ and the advanced bash programming
guide, although that adds another 300+ pages and I haven't printed 'em out
yet because I'd need another ream of paper and a second binder. But I've got
the pdfs on my laptop.)

5) Read about the historical bourne, korn, and c shells. (I hate to recommend
the wikipedia articles, but it's a start and they link to other stuff. "csh
programming considered harmful" has a few interesting bits.)

6) Ponder the really weird corner cases of parsing, like embedded nul bytes in
the output of backquote commands. Check to see what bash does. Take more
notes. (Pop quiz: why is having two spaces between "one" and "two" in
echo "$(echo "one two")"
a much better test then just having one space there?)

7) Break the whole mess down into functional sub-units like job control and
terminal control, and then ponder each of _their_ weird corner cases, like
what happens when you type "read i" on the command line and hit ctrl-z?
Notice that the read command is like cd and exit: it can't be a background
process because the point of the thing is to set an environment variable, and
that environment variable would go away when the background process did.
(Other fun things to try ctrl-z with include "sleep 5 && ls | sort", "sleep
5 ; ls | sort", and of course "sleep 5 | wc". Then go back through the specs
and figure out how much of that behavior is actually _required_, and how much
is an implementation idiosyncrasy. That's still a todo item of mine.)

8) Work out how the functional sub-units interact with each other. Can quote
parsing and pipes/redirects be separated so you can arbitrarily disable one
but not the other? What features require a union of otherwise orthogonal
functional groups? (Look at ctrl-z: You need both job control and terminal
control for that, but job control and terminal control shouldn't depend on
each other because you can detach processes with & in a shell script and you
should be able to kill things with ctrl-c even when you can't background
them.)

According to http://busybox.net/~landley/notes.html my first "hello world"
version of bbsh was November 7, 2005, but that wasn't when I started on it.
I'd been studying what was required for a while. The October 14 entry
mentions my intention to do it, but I'd been poking at it before then. The
reason for the big gap between last November and when I put the "tiniest
possible shell I can do" into the tree was that my early attempts at this
only proved to me how little I knew about the problem space, and I had to go
study lots and lots and lots.

We have four shells in the tree right now. "Doing a shell" is not a major
limiting factor. I want to do it _right_, so we can have _fewer_ shells..
Post by Bernhard Fischer
That
resize applet serves a unique, established purpose that shouldn't be
hindered by eventual progress you as a single person achieve with bringing
bbsh forward.
If we're going to have it in the tree, we should do it right.

And I'd already added equivalent functionality to bbsh (remember how I worked
out a functional probe string without actually seeing the other code), and
when I found out that resize was an existing applet I wanted to generalize
that code.

I also don't know why the resize applet you submitted was resetting terminal
parameters _before_ doing the probing.
Post by Bernhard Fischer
Post by Rob Landley
Also, I'd rather not add new code into the tree with "or later" and then have
to go back and remove it as I get around to making the license notices
uniform.
I would have removed the or later in a day or two, if the applet was
still in the tree
I meant to put the darn thing back into the tree yesterday, but the SFLC
scheduled a teleconference they want both me and Bruce on, and I got another
headache and had to go lie down. (I'll be _so_ happy when Bruce finally goes
back to his crypt. This is _not_ good for my health.)

Then this morning my laptop decided to do a fresh reboot rather than
resume-from-suspend, so I lost my open window and have to track down the
patch again. (Software suspend on Ubuntu 6.06 is _really_ flaky. I think
the problem is that my laptop's hard drive has an onboard buffer that only
sometimes flushes the last block before the power goes off, and when it
doesn't the swap partition has all the resume data in it but doesn't have the
start of the partition marked as a suspend image instead of normal swap. I'd
blame the hardware, except that earlier versions of ubuntu didn't do this
(they had _different_ bugs). I think it's actually the kernel missing a
flush somewhere in the suspend to disk path.)

No, I haven't built my own kernel for my laptop. Last time I tried it,
getting the ipw2200 firmware loading to line up again was enough of a pain I
gave up, and I've been way too busy to get back to it...

But mostly? Weekend. Tired. Sleeping muchly, visiting Ikea, reading... ok,
reading the OLS2006 proceedings but _also_ reading a fluffy Wen Spencer book
about elves and dragons and such.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-24 09:30:21 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.
Ok, preserving the behavior of that strikes me as a good thing. I guess
that
Post by Bernhard Fischer
I've applied it as r16176 for now.
Feel free to wipe it out of the tree like you did with taskset, if you
feel like.
Done.
Thanks so much.
Post by Rob Landley
"I'll think about it" != "Ooh, that means I should apply it". It means I need
to think about how best to do this.
The purpose of this applet is to run from the command line? Or are we
It's purpose is to be run interactively (only, i'd say).
Post by Rob Landley
encouraging people to have it in their /etc/profile? If they start typing
before their /etc/profile runs (or they "echo command | sh", don't we have
the same problem with bbsh interactive mode, where it shouldn't do this if
there's already data waiting on stdin? (Or should it discard any data
waiting on stdin?)
I don't understand what you're saying here. Please explain?
Post by Rob Landley
And _if_ we do this, I'd like to re-use the code that bbsh is using to do this
probing for interactive mode, rather than having two implementations in the
tree. I believe I _said_ that.
bbsh doesn't have that code AFAICS.
You don't seem to want to collaborate with anybody wrt bbsh. That
resize applet serves a unique, established purpose that shouldn't be
hindered by eventual progress you as a single person achieve with bringing
bbsh forward.
Post by Rob Landley
Also, I'd rather not add new code into the tree with "or later" and then have
to go back and remove it as I get around to making the license notices
uniform.
I would have removed the or later in a day or two, if the applet was
still in the tree
Rob Landley
2006-09-22 18:54:11 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.
Ok, preserving the behavior of that strikes me as a good thing. I guess that
I've applied it as r16176 for now.
Feel free to wipe it out of the tree like you did with taskset, if you
feel like.
Done.

"I'll think about it" != "Ooh, that means I should apply it". It means I need
to think about how best to do this.

The purpose of this applet is to run from the command line? Or are we
encouraging people to have it in their /etc/profile? If they start typing
before their /etc/profile runs (or they "echo command | sh", don't we have
the same problem with bbsh interactive mode, where it shouldn't do this if
there's already data waiting on stdin? (Or should it discard any data
waiting on stdin?)

And _if_ we do this, I'd like to re-use the code that bbsh is using to do this
probing for interactive mode, rather than having two implementations in the
tree. I believe I _said_ that.

Also, I'd rather not add new code into the tree with "or later" and then have
to go back and remove it as I get around to making the license notices
uniform.
Post by Bernhard Fischer
Post by Rob Landley
I am already not getting warnings about unused parameters. Why are you
getting them?
because i asked to get them since they remind me that it's a todo (for
me, at least) ;)
Why? What's the point? You ask the compiler to give you a warning and then
you tell the compiler not to give you that warning _here_. Why do this
thing? There are often good reasons for unused function parameters. There
are never good reasons for unused local variables.

I really don't want to fill the tree with "humor the compiler's warning
generator" markup. I repeat, I don't ask the compiler to give me warnings
that it's not capable of generating competently.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-22 07:27:47 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
I've been pondering switching argv and argc to globals for most of a year (I
suggested it on the list before), but lemme get bbsh into reasonable shape
And i implemented and sent the patch to the list before.
See
http://www.busybox.net/lists/busybox/2006-July/023016.html

Made the binary bigger (for me)..
Bernhard Fischer
2006-09-22 07:44:32 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
[snip global argv]
Post by Rob Landley
Post by Bernhard Fischer
Easy to fix (i have a patch here at home which did this, against an
ancient version) but i'm not convinced if Rob likes this or not as it
would make the applet dispatch-table filler macros even less
comprehensible.
Rob?
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?
provide means to let applets be of the form

variant_A_main(void)
variant_B_main(int argc)
variant_C_main(char **argv)
variant_D_main(int argc, char **argv)

by making the PROTOTYPES peruse
#define _BB_NOARG (void)
#define _BB_ARGC (int argc)
#define _BB_ARGV (char **argv)
#define _BB_ARGS (int argc, char **argv)

via


Index: include/applets.h
===================================================================
--- include/applets.h (revision 16172)
+++ include/applets.h (working copy)
@@ -15,11 +15,15 @@
#undef APPLET_ODDNAME
#undef APPLET_NOUSAGE

+#define _BB_NOARG (void)
+#define _BB_ARGC (int argc)
+#define _BB_ARGV (char **argv)
+#define _BB_ARGS (int argc, char **argv)

#if defined(PROTOTYPES)
-# define APPLET(a,b,c) extern int a##_main(int argc, char **argv);
-# define APPLET_NOUSAGE(a,b,c,d) extern int b##_main(int argc, char
**argv);
-# define APPLET_ODDNAME(a,b,c,d,e) extern int b##_main(int argc, char
**argv);
+# define APPLET(a,b,c) extern int a##_main ## c;
+# define APPLET_NOUSAGE(a,b,c,d) extern int b##_main ## c;
+# define APPLET_ODDNAME(a,b,c,d,e) extern int b##_main ## c;
#elif defined(MAKE_USAGE)
# ifdef CONFIG_FEATURE_VERBOSE_USAGE
# define APPLET(a,b,c) a##_trivial_usage "\n\n" a##_full_usage "\0"


so you can say (e.g. for test):

@@ -47,7 +51,7 @@
#endif


-USE_TEST(APPLET_NOUSAGE([, test, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_TEST(APPLET_NOUSAGE([, test, _BB_ARGS, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_TEST(APPLET_NOUSAGE([[, test, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_ADDGROUP(APPLET(addgroup, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_ADDUSER(APPLET(adduser, _BB_DIR_BIN, _BB_SUID_NEVER))
Bernhard Fischer
2006-09-22 08:25:10 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.
Ok, preserving the behavior of that strikes me as a good thing. I guess that
I've applied it as r16176 for now.
Feel free to wipe it out of the tree like you did with taskset, if you
feel like.
Post by Rob Landley
means I should take another look at the patch...
+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
What on _earth_?
The version i checked in doesn't set a timeout. It can easily be fixed
later on, if needed (i wouldn't be surprised if a timeout handling is
needed in the wild).
Post by Rob Landley
+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {
The curly bracket goes on the start of the next line.
done.
Post by Rob Landley
I am already not getting warnings about unused parameters. Why are you
getting them?
because i asked to get them since they remind me that it's a todo (for
me, at least) ;)

cheers,
Bernhard
Rob Landley
2006-09-22 03:35:42 UTC
Permalink
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird tuneables
that don't save size. It's not for adding extra warnings, either. And
currently, it doesn't work properly and won't until I fix some stuff in
menuconfig, which is blocked until we upgrade to the new version from current
kernels, which Denis was working on last I heard.

In this case, there's no reason for that to _be_ a tuneable. Either it works
or it doesn't work, and if it's broken we should fix it. (You don't put in a
tuneable for a potential _bug_.)

A standalone resize applet can have a full second's delay, or even two; if
you're going to call the sucker then you can expect it to wait until it gets
an answer. It's something like an automatic call in bbsh (a heuristic that
can fail) that needs a short (preferably imperceptible) timeout.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-22 07:50:43 UTC
Permalink
Post by Rob Landley
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird tuneables
It can depend on CONFIG_NITPICK to eventually show a
CONFIG_RESIZE_TERMIOS_TIMEOUT config entry. But it's so trivial to
change in the source, than i'm fond of talking about it.
I thought that you and rpjday wanted to empower users to toggle stuff
with the configury so they do not have to edit the source. Maybe i
remember incorrectly or misunderstood your and/or rpjday's intentions.
*shrug*.
Post by Rob Landley
that don't save size. It's not for adding extra warnings, either. And
currently, it doesn't work properly and won't until I fix some stuff in
menuconfig, which is blocked until we upgrade to the new version from current
kernels, which Denis was working on last I heard.
Rob Landley
2006-09-22 18:33:39 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird tuneables
It can depend on CONFIG_NITPICK to eventually show a
CONFIG_RESIZE_TERMIOS_TIMEOUT config entry. But it's so trivial to
change in the source, than i'm fond of talking about it.
I thought that you and rpjday wanted to empower users to toggle stuff
with the configury so they do not have to edit the source.
I think that having a CONFIG option is superior to having a comment in the
source that says "these three lines can be chopped out and replaced with a
hardwired constant if you're really low on space".

However, if somebody doesn't like the timeout and is motivated to track it
down, it shouldn't take them too long to find it. (It won't occur to them
that they _can't_ change the timeout, if they decide they need to.)
Post by Bernhard Fischer
Post by Rob Landley
kernels, which Denis was working on last I heard.
From current klibc, you mean.
The kernel makefile guy explicitely stated that we're better off to use
the more generic klibc stuff, so why do you want to disregard his hint?
Just curious..
We don't, I just haven't heard back from Denis on his progress. (He's been
off banging on mount.c instead.) The only drop I have from him so far is
based on linux-2.6.17 and is what prompted the klibc hint from the
maintainer. :)

I'm happy to wait for Denis if he thinks he can have it ready in time for the
December release, I just haven't heard anything. Next month I'll start to
worry. :)
Post by Bernhard Fischer
Post by Rob Landley
In this case, there's no reason for that to _be_ a tuneable. Either it works
or it doesn't work, and if it's broken we should fix it. (You don't put in a
tuneable for a potential _bug_.)
What the are you talking about? If a terminal doesn't respond for
whatever reason, why is that a bug?
If we're not waiting long enough to reliably receive the response in an applet
that has no purpose other than to query for this information, that is a bug.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-24 09:18:20 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird
tuneables
Post by Bernhard Fischer
It can depend on CONFIG_NITPICK to eventually show a
CONFIG_RESIZE_TERMIOS_TIMEOUT config entry. But it's so trivial to
change in the source, than i'm fond of talking about it.
I thought that you and rpjday wanted to empower users to toggle stuff
with the configury so they do not have to edit the source.
I think that having a CONFIG option is superior to having a comment in the
source that says "these three lines can be chopped out and replaced with a
hardwired constant if you're really low on space".
However, if somebody doesn't like the timeout and is motivated to track it
down, it shouldn't take them too long to find it. (It won't occur to them
that they _can't_ change the timeout, if they decide they need to.)
fair enough.
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
In this case, there's no reason for that to _be_ a tuneable. Either it
works
Post by Bernhard Fischer
Post by Rob Landley
or it doesn't work, and if it's broken we should fix it. (You don't put in
a
Post by Bernhard Fischer
Post by Rob Landley
tuneable for a potential _bug_.)
What the are you talking about? If a terminal doesn't respond for
whatever reason, why is that a bug?
If we're not waiting long enough to reliably receive the response in an applet
that has no purpose other than to query for this information, that is a bug.
Yes, i see what you mean. The big, "established" application does set
it's timeout to 10 seconds according to pgf, so the implementation i
suggested just kept that 10 seconds timeout as a way to specify least
deviation from the expected behaviour.
Bernhard Fischer
2006-09-24 09:18:20 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird
tuneables
Post by Bernhard Fischer
It can depend on CONFIG_NITPICK to eventually show a
CONFIG_RESIZE_TERMIOS_TIMEOUT config entry. But it's so trivial to
change in the source, than i'm fond of talking about it.
I thought that you and rpjday wanted to empower users to toggle stuff
with the configury so they do not have to edit the source.
I think that having a CONFIG option is superior to having a comment in the
source that says "these three lines can be chopped out and replaced with a
hardwired constant if you're really low on space".
However, if somebody doesn't like the timeout and is motivated to track it
down, it shouldn't take them too long to find it. (It won't occur to them
that they _can't_ change the timeout, if they decide they need to.)
fair enough.
Post by Rob Landley
Post by Bernhard Fischer
Post by Rob Landley
In this case, there's no reason for that to _be_ a tuneable. Either it
works
Post by Bernhard Fischer
Post by Rob Landley
or it doesn't work, and if it's broken we should fix it. (You don't put in
a
Post by Bernhard Fischer
Post by Rob Landley
tuneable for a potential _bug_.)
What the are you talking about? If a terminal doesn't respond for
whatever reason, why is that a bug?
If we're not waiting long enough to reliably receive the response in an applet
that has no purpose other than to query for this information, that is a bug.
Yes, i see what you mean. The big, "established" application does set
it's timeout to 10 seconds according to pgf, so the implementation i
suggested just kept that 10 seconds timeout as a way to specify least
deviation from the expected behaviour.
Rob Landley
2006-09-22 18:33:39 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird tuneables
It can depend on CONFIG_NITPICK to eventually show a
CONFIG_RESIZE_TERMIOS_TIMEOUT config entry. But it's so trivial to
change in the source, than i'm fond of talking about it.
I thought that you and rpjday wanted to empower users to toggle stuff
with the configury so they do not have to edit the source.
I think that having a CONFIG option is superior to having a comment in the
source that says "these three lines can be chopped out and replaced with a
hardwired constant if you're really low on space".

However, if somebody doesn't like the timeout and is motivated to track it
down, it shouldn't take them too long to find it. (It won't occur to them
that they _can't_ change the timeout, if they decide they need to.)
Post by Bernhard Fischer
Post by Rob Landley
kernels, which Denis was working on last I heard.
From current klibc, you mean.
The kernel makefile guy explicitely stated that we're better off to use
the more generic klibc stuff, so why do you want to disregard his hint?
Just curious..
We don't, I just haven't heard back from Denis on his progress. (He's been
off banging on mount.c instead.) The only drop I have from him so far is
based on linux-2.6.17 and is what prompted the klibc hint from the
maintainer. :)

I'm happy to wait for Denis if he thinks he can have it ready in time for the
December release, I just haven't heard anything. Next month I'll start to
worry. :)
Post by Bernhard Fischer
Post by Rob Landley
In this case, there's no reason for that to _be_ a tuneable. Either it works
or it doesn't work, and if it's broken we should fix it. (You don't put in a
tuneable for a potential _bug_.)
What the are you talking about? If a terminal doesn't respond for
whatever reason, why is that a bug?
If we're not waiting long enough to reliably receive the response in an applet
that has no purpose other than to query for this information, that is a bug.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-22 07:50:43 UTC
Permalink
Post by Rob Landley
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird tuneables
It can depend on CONFIG_NITPICK to eventually show a
CONFIG_RESIZE_TERMIOS_TIMEOUT config entry. But it's so trivial to
change in the source, than i'm fond of talking about it.
I thought that you and rpjday wanted to empower users to toggle stuff
with the configury so they do not have to edit the source. Maybe i
remember incorrectly or misunderstood your and/or rpjday's intentions.
*shrug*.
Post by Rob Landley
that don't save size. It's not for adding extra warnings, either. And
currently, it doesn't work properly and won't until I fix some stuff in
menuconfig, which is blocked until we upgrade to the new version from current
kernels, which Denis was working on last I heard.
From current klibc, you mean.
The kernel makefile guy explicitely stated that we're better off to use
the more generic klibc stuff, so why do you want to disregard his hint?
Just curious..
Post by Rob Landley
In this case, there's no reason for that to _be_ a tuneable. Either it works
or it doesn't work, and if it's broken we should fix it. (You don't put in a
tuneable for a potential _bug_.)
What the are you talking about? If a terminal doesn't respond for
whatever reason, why is that a bug?
Rob Landley
2006-09-22 03:25:04 UTC
Permalink
Post by Bernhard Fischer
Post by Tito
And, what is this for?
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations that are too trivial to bother
most people with. It's the next step up from going in and twiddling the
source code yourself.
Post by Bernhard Fischer
It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.
The normal binary? (Rummage...) Ah, so there is. Part of X from _1984_.
Wow.

Ok, preserving the behavior of that strikes me as a good thing. I guess that
means I should take another look at the patch...

+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)

What on _earth_?

+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {

The curly bracket goes on the start of the next line.

Have we been using ATTRIBUTE_UNUSED on argc and argv anywhere else? Is this
really needed? We've never appled ATTRIBUTE_UNUSED to argc and argv that I'm
aware of. If coreutils/sync.c hasn't been using this (ever), and no I'm not
recommending adding it. Why is that there?
Post by Bernhard Fischer
ATTRIBUTE_UNUSED just sets TREE_NO_WARNING (or however it's spelled) so
you don't get warnings about unused parameters.
I am already not getting warnings about unused parameters. Why are you
getting them?
Post by Bernhard Fischer
Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.
I've been pondering switching argv and argc to globals for most of a year (I
suggested it on the list before), but lemme get bbsh into reasonable shape
first.
Post by Bernhard Fischer
Easy to fix (i have a patch here at home which did this, against an
ancient version) but i'm not convinced if Rob likes this or not as it
would make the applet dispatch-table filler macros even less
comprehensible.
Rob?
Mind if Tito or i do this, mid-term?
Do which? What specifically are you proposing?

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-22 03:35:42 UTC
Permalink
Ok, having caught up on the rest of the thread (being copied on just _some_
Post by Bernhard Fischer
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.
CONFIG_NITPICK is for minor size optimizations. It's not for weird tuneables
that don't save size. It's not for adding extra warnings, either. And
currently, it doesn't work properly and won't until I fix some stuff in
menuconfig, which is blocked until we upgrade to the new version from current
kernels, which Denis was working on last I heard.

In this case, there's no reason for that to _be_ a tuneable. Either it works
or it doesn't work, and if it's broken we should fix it. (You don't put in a
tuneable for a potential _bug_.)

A standalone resize applet can have a full second's delay, or even two; if
you're going to call the sucker then you can expect it to wait until it gets
an answer. It's something like an automatic call in bbsh (a heuristic that
can fail) that needs a short (preferably imperceptible) timeout.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-21 21:45:23 UTC
Permalink
Post by Bernhard Fischer
snip
Post by Bernhard Fischer
text data bss dec hex filename
223 0 0 223 df console-tools/resize.o
Hi,
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+???????new.c_cc[VMIN] = 0;
+???????new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif
Just out of curiosity, why do you use all this defines if
#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = 100; /* Timeout in deciseconds */
And, what is this for?
It provides for easily setting the TIOS timeout in the NITPICK sectio of
libbb library tuning, i guess.

pgf said that the thing he looked at had a 10 second delay, and that's
just a trivial way to make it configurable without mocking much with the
source later on. It can certainly be dropped and hardcoded, yes.
Post by Bernhard Fischer
???????if (00 && argc > 1)
???????????????printf("COLUMNS=%d;LINES=%d;export COLUMNS LINES;",
???????????????????????w.ws_col, w.ws_row);
What is 00?
0

It's ment as a suggestion to emit the string conditionally in case
somebody wants to preserve the behaviour of the bloated normal binary
that is not in busybox.

Since i deny the need for adding several newlines (three) for no good
reason, i provided the string that i would like to see there that has
the same effect like the bloated version but is smaller.
Post by Bernhard Fischer
int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv)
Maybe I'm not smart enough to understand this magics.....
ATTRIBUTE_UNUSED just sets TREE_NO_WARNING (or however it's spelled) so
you don't get warnings about unused parameters. Unfortunately we
currently cannot say the proper (and size-saving!)
int my_applet_main(void){} due to our macros being stubborn.

Easy to fix (i have a patch here at home which did this, against an
ancient version) but i'm not convinced if Rob likes this or not as it
would make the applet dispatch-table filler macros even less
comprehensible.

Rob?
Mind if Tito or i do this, mid-term?
Tito
2006-09-21 21:26:44 UTC
Permalink
On Thursday 21 September 2006 23:04, Bernhard Fischer wrote:

snip
Post by Bernhard Fischer
text data bss dec hex filename
223 0 0 223 df console-tools/resize.o
Hi,

+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+???????new.c_cc[VMIN] = 0;
+???????new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif

Just out of curiosity, why do you use all this defines if

#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */

is always defined, wouldn't it be cleaner:

new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = 100; /* Timeout in deciseconds */


And, what is this for?

???????if (00 && argc > 1)
???????????????printf("COLUMNS=%d;LINES=%d;export COLUMNS LINES;",
???????????????????????w.ws_col, w.ws_row);

What is 00?
Why you are testing for argc > 1 when you previously declared:

int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv)

Maybe I'm not smart enough to understand this magics.....

Ciao,
Tito
Dave Hylands
2006-09-21 23:16:32 UTC
Permalink
Hi Bernhard,

Replying to the list this time.
Post by Bernhard Fischer
The attached should actually work for settion the w/h.
Dave, can you test this please?
I hacked the bits into my busybox 1.1.2 and verified that it works on
my gumstix.

# winsize
Width = 0, Height = 0
# busybox.new resize
# winsize
Width = 111, Height = 79

winsize is my test program that calls ioctl with TIOCGWINSZ, and the
width and height indeed match my current settings, and I verified that
vi behaves as expected.

Thanks
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
Bernhard Fischer
2006-09-24 09:32:29 UTC
Permalink
Post by Dave Hylands
Hi Bernhard,
Replying to the list this time.
Post by Bernhard Fischer
The attached should actually work for settion the w/h.
Dave, can you test this please?
I hacked the bits into my busybox 1.1.2 and verified that it works on
my gumstix.
# winsize
Width = 0, Height = 0
# busybox.new resize
# winsize
Width = 111, Height = 79
winsize is my test program that calls ioctl with TIOCGWINSZ, and the
width and height indeed match my current settings, and I verified that
vi behaves as expected.
Thanks
Thanks for verifying.
Bernhard Fischer
2006-09-24 09:32:29 UTC
Permalink
Post by Dave Hylands
Hi Bernhard,
Replying to the list this time.
Post by Bernhard Fischer
The attached should actually work for settion the w/h.
Dave, can you test this please?
I hacked the bits into my busybox 1.1.2 and verified that it works on
my gumstix.
# winsize
Width = 0, Height = 0
# busybox.new resize
# winsize
Width = 111, Height = 79
winsize is my test program that calls ioctl with TIOCGWINSZ, and the
width and height indeed match my current settings, and I verified that
vi behaves as expected.
Thanks
Thanks for verifying.
Rob Landley
2006-09-22 02:55:43 UTC
Permalink
Post by Bernhard Fischer
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
I don't, no. What's wrong with having bbsh do this again? (And if you want
an external applet to do this, I'd prefer reuse the code I put into bbsh
yesterday. Haven't had a chance to test it over a serial line yet...)

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-24 18:18:58 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
I don't, no.
Noted.
Post by Rob Landley
What's wrong with having bbsh do this again?
Not everyone will use that currently non-existing so called "bbsh".
Don't forget the users that will run any other non-busybox provided
shell and still want to use busybox's coreutils or console-utils
replacements.

The mythical bbsh may be (still don't see why it is concerned about it,
but i know nothing about shells) a user of it, just like it may become
(currently is not) a user of bb_echo, but fact is that it ATM is not.

Also, having "bbsh" be a user would help in no way if a user decided not
to use it (and not to use bbsh's reimplementation of uudecode et al for
that matter).
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
Post by Rob Landley
(And if you want
an external applet to do this, I'd prefer reuse the code I put into bbsh
yesterday. Haven't had a chance to test it over a serial line yet...)
No idea what you're referring to. The only change i recently saw that
was checked into shell/bbsh.c was reverting vda's attempt to touch
bbsh.c:

------------------------------------------------------------------------
r16166 | landley | 2006-09-20 23:57:36 +0200 (Wed, 20 Sep 2006) | 5
lines

The version checked into the tree is a snapshot of an unifinished
applet, and
you just made lots of ">>>>>>> mine" lines show up in my working copy of
this.

Please don't do that again.

------------------------------------------------------------------------
r16142 | vda | 2006-09-17 18:28:10 +0200 (Sun, 17 Sep 2006) | 3 lines

whitespace cleanup


I.e you did NOT put anything at all into bbsh yesterday (22th Sep 2006
or the like).

While you said this when i dared to send you some *comments* WRT the
current source of bbsh that is in the tree:

me> Random comments while reading the currently visible incarnation..
landley> I didn't ask. You're critiquing a random snapshot of code
landley> that's NOT FINISHED.

http://www.busybox.net/lists/busybox/2006-September/024428.html
http://www.busybox.net/lists/busybox/2006-September/024443.html
Rob Landley
2006-09-25 06:37:14 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
I don't, no.
Noted.
Post by Rob Landley
What's wrong with having bbsh do this again?
Not everyone will use that currently non-existing so called "bbsh".
Not everyone will use BusyBox, either.
Post by Bernhard Fischer
Don't forget the users that will run any other non-busybox provided
shell and still want to use busybox's coreutils or console-utils
replacements.
Sure. And resize is part of x11. Are we bolting bits of that onto BusyBox
now?
Post by Bernhard Fischer
The mythical bbsh may be (still don't see why it is concerned about it,
but i know nothing about shells)
And yet you're complaining I'm not letting you help develop it.

For your information, the shell is already concerned because it has to set
$LINES and $COLUMNS, and reset them when it gets SIGWINCH. It also needs to
know how wide the screen is in order to know when it hits the left edge of
the screen during backspace, because for some reason your average unix TTY
doesn't back up to the end of the previous line so you have to cursor up and
jump to EOL yourself, and know when to do it.

The first report I got about this problem was from somebody upset that the
shell's backspace thing wasn't working right:
http://www.busybox.net/lists/busybox/2006-June/022794.html

I already mentioned that reliably using a probing method that performs in-band
signaling (which the ANSI query does) requires fairly careful setup. Or, you
can simply not care about reliability at all, and wait for the next round of
bug reports from somebody who put it in their /etc/profile and can't figure
out why it's causing problems.
Post by Bernhard Fischer
Also, having "bbsh" be a user would help in no way if a user decided not
to use it (and not to use bbsh's reimplementation of uudecode et al for
that matter).
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
No, but this would be the first x11 utility we'd added to the thing. At what
point do we suck in xvidtune? (Congratulations, you just convinced me that
it probably shouldn't go in.)
Post by Bernhard Fischer
No idea what you're referring to. The only change i recently saw that
was checked into shell/bbsh.c was reverting vda's attempt to touch
My copy's had a couple weeks of development since then (although I'd planned
to spend last week on it and wound up dealing with Bruce instead, and didn't
get to spend any of this weekend on it because I was so backlogged with other
things. But I do get some stuff done during the week.)
Post by Bernhard Fischer
I.e you did NOT put anything at all into bbsh yesterday (22th Sep 2006
or the like).
I put it into my copy, on my laptop. I haven't checked the copy on my laptop
in yet because it contains large chunks of code that don't currently work as
intended.
Post by Bernhard Fischer
While you said this when i dared to send you some *comments* WRT the
You yourself just said you know nothing about shells. Was this incorrect?

We currently have four other shells in the tree. They've been there years,
and haven't significantly been cleaned up or unified before I started doing
it myself. (There was at least one major previous attempt, which is how we
got the fourth shell.)

I'm trying to write a new shell that solves a large number of interconnected
problems with a small amount of code, and this requires extensive thought
about how to go about it up front. Just getting the _parsing_ right is very
much nontrivial. I've been studying this problem for a _year_ now, and I'm
still struggling with large chunks of it. You want to help _without_ first
studying the problem, simply by commenting on what I've done.

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-25 06:37:14 UTC
Permalink
Post by Bernhard Fischer
Post by Rob Landley
Post by Bernhard Fischer
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
I don't, no.
Noted.
Post by Rob Landley
What's wrong with having bbsh do this again?
Not everyone will use that currently non-existing so called "bbsh".
Not everyone will use BusyBox, either.
Post by Bernhard Fischer
Don't forget the users that will run any other non-busybox provided
shell and still want to use busybox's coreutils or console-utils
replacements.
Sure. And resize is part of x11. Are we bolting bits of that onto BusyBox
now?
Post by Bernhard Fischer
The mythical bbsh may be (still don't see why it is concerned about it,
but i know nothing about shells)
And yet you're complaining I'm not letting you help develop it.

For your information, the shell is already concerned because it has to set
$LINES and $COLUMNS, and reset them when it gets SIGWINCH. It also needs to
know how wide the screen is in order to know when it hits the left edge of
the screen during backspace, because for some reason your average unix TTY
doesn't back up to the end of the previous line so you have to cursor up and
jump to EOL yourself, and know when to do it.

The first report I got about this problem was from somebody upset that the
shell's backspace thing wasn't working right:
http://www.busybox.net/lists/busybox/2006-June/022794.html

I already mentioned that reliably using a probing method that performs in-band
signaling (which the ANSI query does) requires fairly careful setup. Or, you
can simply not care about reliability at all, and wait for the next round of
bug reports from somebody who put it in their /etc/profile and can't figure
out why it's causing problems.
Post by Bernhard Fischer
Also, having "bbsh" be a user would help in no way if a user decided not
to use it (and not to use bbsh's reimplementation of uudecode et al for
that matter).
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
No, but this would be the first x11 utility we'd added to the thing. At what
point do we suck in xvidtune? (Congratulations, you just convinced me that
it probably shouldn't go in.)
Post by Bernhard Fischer
No idea what you're referring to. The only change i recently saw that
was checked into shell/bbsh.c was reverting vda's attempt to touch
My copy's had a couple weeks of development since then (although I'd planned
to spend last week on it and wound up dealing with Bruce instead, and didn't
get to spend any of this weekend on it because I was so backlogged with other
things. But I do get some stuff done during the week.)
Post by Bernhard Fischer
I.e you did NOT put anything at all into bbsh yesterday (22th Sep 2006
or the like).
I put it into my copy, on my laptop. I haven't checked the copy on my laptop
in yet because it contains large chunks of code that don't currently work as
intended.
Post by Bernhard Fischer
While you said this when i dared to send you some *comments* WRT the
You yourself just said you know nothing about shells. Was this incorrect?

We currently have four other shells in the tree. They've been there years,
and haven't significantly been cleaned up or unified before I started doing
it myself. (There was at least one major previous attempt, which is how we
got the fourth shell.)

I'm trying to write a new shell that solves a large number of interconnected
problems with a small amount of code, and this requires extensive thought
about how to go about it up front. Just getting the _parsing_ right is very
much nontrivial. I've been studying this problem for a _year_ now, and I'm
still struggling with large chunks of it. You want to help _without_ first
studying the problem, simply by commenting on what I've done.

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-24 18:18:58 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
I don't, no.
Noted.
Post by Rob Landley
What's wrong with having bbsh do this again?
Not everyone will use that currently non-existing so called "bbsh".
Don't forget the users that will run any other non-busybox provided
shell and still want to use busybox's coreutils or console-utils
replacements.

The mythical bbsh may be (still don't see why it is concerned about it,
but i know nothing about shells) a user of it, just like it may become
(currently is not) a user of bb_echo, but fact is that it ATM is not.

Also, having "bbsh" be a user would help in no way if a user decided not
to use it (and not to use bbsh's reimplementation of uudecode et al for
that matter).
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
Post by Rob Landley
(And if you want
an external applet to do this, I'd prefer reuse the code I put into bbsh
yesterday. Haven't had a chance to test it over a serial line yet...)
No idea what you're referring to. The only change i recently saw that
was checked into shell/bbsh.c was reverting vda's attempt to touch
bbsh.c:

------------------------------------------------------------------------
r16166 | landley | 2006-09-20 23:57:36 +0200 (Wed, 20 Sep 2006) | 5
lines

The version checked into the tree is a snapshot of an unifinished
applet, and
you just made lots of ">>>>>>> mine" lines show up in my working copy of
this.

Please don't do that again.

------------------------------------------------------------------------
r16142 | vda | 2006-09-17 18:28:10 +0200 (Sun, 17 Sep 2006) | 3 lines

whitespace cleanup


I.e you did NOT put anything at all into bbsh yesterday (22th Sep 2006
or the like).

While you said this when i dared to send you some *comments* WRT the
current source of bbsh that is in the tree:

me> Random comments while reading the currently visible incarnation..
landley> I didn't ask. You're critiquing a random snapshot of code
landley> that's NOT FINISHED.

http://www.busybox.net/lists/busybox/2006-September/024428.html
http://www.busybox.net/lists/busybox/2006-September/024443.html
Bernhard Fischer
2006-09-21 21:04:54 UTC
Permalink
Post by Bernhard Fischer
Post by Rich Felker
IMO (and I seem recall someone else in the thread saying the same)
setting the variables is not a good idea anyway, so it's probably not
useful to print these.
Post by Bernhard Fischer
That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)
I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Yeah somewhere like that, I suppose. And if it's going in BB there's
no problem with using stdio, etc. since they'll already be linked
anyway. Avoiding them is only useful for tiny standalone programs.
The attached should actually work for settion the w/h.
Dave, can you test this please?
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
function old new delta
resize_main - 220 +220
.rodata 174048 174096 +48
static.check_mntent_file 760 776 +16
static.e2fsck_pass1 7804 7816 +12
evaltreenr 623 633 +10
evaltree 623 633 +10
static.add_interface 300 302 +2
static.qrealloc 45 44 -1
static.glob3 37 35 -2
busybox_main 472 470 -2
static.popstring 150 147 -3
static.parse_opts 61 56 -5
static.diffreg 2945 2938 -7
static.new_init_module 505 497 -8
ext2fs_open_inode_scan 403 391 -12
ed_main 3348 3323 -25
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 6/9 up/down: 318/-65) Total: 253 bytes
(IMA, size)
$ size busybox_old busybox
text data bss dec hex filename
823938 6436 239444 1069818 1052fa busybox_old
824224 6440 239444 1070108 10541c busybox
(legacy, size)
$ size console-tools/resize.o
text data bss dec hex filename
254 0 0 254 fe console-tools/resize.o
And without being actively stoopid:
text data bss dec hex filename
223 0 0 223 df console-tools/resize.o

-------------- next part --------------
Index: console-tools/Makefile.in
===================================================================
--- console-tools/Makefile.in (revision 16161)
+++ console-tools/Makefile.in (working copy)
@@ -20,6 +20,7 @@ CONSOLETOOLS-$(CONFIG_LOADFONT) += loadf
CONSOLETOOLS-$(CONFIG_LOADKMAP) += loadkmap.o
CONSOLETOOLS-$(CONFIG_OPENVT) += openvt.o
CONSOLETOOLS-$(CONFIG_RESET) += reset.o
+CONSOLETOOLS-$(CONFIG_RESIZE) += resize.o
CONSOLETOOLS-$(CONFIG_SETKEYCODES) += setkeycodes.o
CONSOLETOOLS-$(CONFIG_SETLOGCONS) += setlogcons.o

Index: console-tools/resize.c
===================================================================
--- console-tools/resize.c (revision 0)
+++ console-tools/resize.c (revision 0)
@@ -0,0 +1,41 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * resize - set terminal width and height.
+ *
+ * Copyright 2006 Bernhard Fischer
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details.
+ */
+/* no options, no getopt */
+#include "busybox.h"
+
+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {
+ /* save_cursor_pos 7
+ * scroll_whole_screen [r
+ * put_cursor_waaaay_off [$x;$yH
+ * get_cursor_pos [6n
+ * restore_cursor_pos 8
+ */
+ struct winsize w = {0,0,0,0};
+ int ret;
+ struct termios old, new;
+ tcgetattr(STDOUT_FILENO, &old); /* fiddle echo */
+ new = old;
+ new.c_cflag |= (CLOCAL | CREAD);
+ new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+ new.c_cc[VMIN] = 0;
+ new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif
+ tcsetattr(STDOUT_FILENO, TCSANOW, &new);
+ printf("\0337\033[r\033[999;999H\033[6n");
+ scanf("\033[%hu;%huR", &w.ws_row, &w.ws_col);
+ ret = ioctl(STDOUT_FILENO, TIOCSWINSZ, &w);
+ printf("\0338");
+ tcsetattr(STDOUT_FILENO, TCSANOW, &old);
+ if (00 && argc > 1)
+ printf("COLUMNS=%d;LINES=%d;export COLUMNS LINES;",
+ w.ws_col, w.ws_row);
+ return ret;
+}
Index: console-tools/Config.in
===================================================================
--- console-tools/Config.in (revision 16161)
+++ console-tools/Config.in (working copy)
@@ -58,6 +58,13 @@ config CONFIG_RESET
This program is used to reset the terminal screen, if it
gets messed up.

+config CONFIG_RESIZE
+ bool "resize"
+ default n
+ help
+ This program is used to (re)set the width and height of your current
+ terminal.
+
config CONFIG_SETCONSOLE
bool "setconsole"
default n
Index: include/libbb.h
===================================================================
--- include/libbb.h (revision 16161)
+++ include/libbb.h (working copy)
@@ -231,8 +231,9 @@ extern void trim(char *s);
extern char *skip_whitespace(const char *);

#ifndef BUILD_INDIVIDUAL
-extern struct BB_applet *find_applet_by_name(const char *name);
-void run_applet_by_name(const char *name, int argc, char **argv);
+extern struct BB_applet *find_applet_by_name(const char *name)
+ USE_FEATURE_SH_STANDALONE_SHELL(ATTRIBUTE_EXTERNALLY_VISIBLE);
+extern void run_applet_by_name(const char *name, int argc, char **argv);
#endif

/* dmalloc will redefine these to it's own implementation. It is safe
Index: include/usage.h
===================================================================
--- include/usage.h (revision 16163)
+++ include/usage.h (working copy)
@@ -2455,6 +2455,11 @@ USE_FEATURE_MDEV_CONFIG( \
#define reset_full_usage \
"Resets the screen."

+#define resize_trivial_usage \
+ ""
+#define resize_full_usage \
+ "Resizes the screen."
+
#define rm_trivial_usage \
"[OPTION]... FILE..."
#define rm_full_usage \
Index: include/applets.h
===================================================================
--- include/applets.h (revision 16161)
+++ include/applets.h (working copy)
@@ -226,6 +226,7 @@ USE_REALPATH(APPLET(realpath, _BB_DIR_US
USE_HALT(APPLET_ODDNAME(reboot, halt, _BB_DIR_SBIN, _BB_SUID_NEVER, reboot))
USE_RENICE(APPLET(renice, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RESET(APPLET(reset, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_RESIZE(APPLET(resize, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RM(APPLET(rm, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMDIR(APPLET(rmdir, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMMOD(APPLET(rmmod, _BB_DIR_SBIN, _BB_SUID_NEVER))
Dave Hylands
2006-09-21 23:16:32 UTC
Permalink
Hi Bernhard,

Replying to the list this time.
Post by Bernhard Fischer
The attached should actually work for settion the w/h.
Dave, can you test this please?
I hacked the bits into my busybox 1.1.2 and verified that it works on
my gumstix.

# winsize
Width = 0, Height = 0
# busybox.new resize
# winsize
Width = 111, Height = 79

winsize is my test program that calls ioctl with TIOCGWINSZ, and the
width and height indeed match my current settings, and I verified that
vi behaves as expected.

Thanks
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
Rob Landley
2006-09-22 02:55:43 UTC
Permalink
Post by Bernhard Fischer
Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?
I don't, no. What's wrong with having bbsh do this again? (And if you want
an external applet to do this, I'd prefer reuse the code I put into bbsh
yesterday. Haven't had a chance to test it over a serial line yet...)

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-21 20:17:44 UTC
Permalink
Post by Rich Felker
IMO (and I seem recall someone else in the thread saying the same)
setting the variables is not a good idea anyway, so it's probably not
useful to print these.
Post by Bernhard Fischer
That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)
I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Yeah somewhere like that, I suppose. And if it's going in BB there's
no problem with using stdio, etc. since they'll already be linked
anyway. Avoiding them is only useful for tiny standalone programs.
The attached should actually work for settion the w/h.
Dave, can you test this please?

Rob, do we want this applied after somebody quickly checked that it's
doing what it is supposed to do?

stats:
(with IMA mode, bloatcheck):
function old new delta
resize_main - 220 +220
.rodata 174048 174096 +48
static.check_mntent_file 760 776 +16
static.e2fsck_pass1 7804 7816 +12
evaltreenr 623 633 +10
evaltree 623 633 +10
static.add_interface 300 302 +2
static.qrealloc 45 44 -1
static.glob3 37 35 -2
busybox_main 472 470 -2
static.popstring 150 147 -3
static.parse_opts 61 56 -5
static.diffreg 2945 2938 -7
static.new_init_module 505 497 -8
ext2fs_open_inode_scan 403 391 -12
ed_main 3348 3323 -25
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 6/9 up/down: 318/-65) Total: 253 bytes

(IMA, size)
$ size busybox_old busybox
text data bss dec hex filename
823938 6436 239444 1069818 1052fa busybox_old
824224 6440 239444 1070108 10541c busybox


(legacy, size)
$ size console-tools/resize.o
text data bss dec hex filename
254 0 0 254 fe console-tools/resize.o

-------------- next part --------------
Index: console-tools/Config.in
===================================================================
--- console-tools/Config.in (revision 16161)
+++ console-tools/Config.in (working copy)
@@ -58,6 +58,13 @@ config CONFIG_RESET
This program is used to reset the terminal screen, if it
gets messed up.

+config CONFIG_RESIZE
+ bool "resize"
+ default n
+ help
+ This program is used to (re)set the width and height of your current
+ terminal.
+
config CONFIG_SETCONSOLE
bool "setconsole"
default n
Index: console-tools/Makefile.in
===================================================================
--- console-tools/Makefile.in (revision 16161)
+++ console-tools/Makefile.in (working copy)
@@ -20,6 +20,7 @@ CONSOLETOOLS-$(CONFIG_LOADFONT) += loadf
CONSOLETOOLS-$(CONFIG_LOADKMAP) += loadkmap.o
CONSOLETOOLS-$(CONFIG_OPENVT) += openvt.o
CONSOLETOOLS-$(CONFIG_RESET) += reset.o
+CONSOLETOOLS-$(CONFIG_RESIZE) += resize.o
CONSOLETOOLS-$(CONFIG_SETKEYCODES) += setkeycodes.o
CONSOLETOOLS-$(CONFIG_SETLOGCONS) += setlogcons.o

Index: console-tools/resize.c
===================================================================
--- console-tools/resize.c (revision 0)
+++ console-tools/resize.c (revision 0)
@@ -0,0 +1,40 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * resize - set terminal width and height.
+ *
+ * Copyright 2006 Bernhard Fischer
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this tarball for details.
+ */
+/* no options, no getopt */
+#include "busybox.h"
+
+#define RESIZE_TIOS_TIMEOUT 100 /* in deciseconds */
+int resize_main(int ATTRIBUTE_UNUSED argc, char ATTRIBUTE_UNUSED **argv) {
+ /* save_cursor_pos 7
+ * scroll_whole_screen [r
+ * put_cursor_waaaay_off [$x;$yH
+ * get_cursor_pos [6n
+ * restore_cursor_pos 8
+ */
+ const char req[] = "\0337\033[r\033[999;999H\033[6n";
+ int f = STDIN_FILENO;
+ struct winsize w = {0,0,0,0};
+ int ret;
+ struct termios old, new;
+ tcgetattr(STDIN_FILENO, &old); /* fiddle echo */
+ new = old;
+ new.c_cflag |= (CLOCAL | CREAD);
+ new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
+#if defined(RESIZE_TIOS_TIMEOUT) && (RESIZE_TIOS_TIMEOUT > 0)
+ new.c_cc[VMIN] = 0;
+ new.c_cc[VTIME] = RESIZE_TIOS_TIMEOUT;
+#endif
+ tcsetattr(STDIN_FILENO, TCSANOW, &new);
+ write(f, req, sizeof req);
+ scanf("\033[%hu;%huR", &w.ws_row, &w.ws_col);
+ ret = ioctl(STDIN_FILENO, TIOCSWINSZ, &w);
+ write(f, "\0338", 2);
+ tcsetattr(STDIN_FILENO, TCSANOW, &old);
+ return ret;
+}
Index: include/libbb.h
===================================================================
--- include/libbb.h (revision 16161)
+++ include/libbb.h (working copy)
@@ -231,8 +231,9 @@ extern void trim(char *s);
extern char *skip_whitespace(const char *);

#ifndef BUILD_INDIVIDUAL
-extern struct BB_applet *find_applet_by_name(const char *name);
-void run_applet_by_name(const char *name, int argc, char **argv);
+extern struct BB_applet *find_applet_by_name(const char *name)
+ USE_FEATURE_SH_STANDALONE_SHELL(ATTRIBUTE_EXTERNALLY_VISIBLE);
+extern void run_applet_by_name(const char *name, int argc, char **argv);
#endif

/* dmalloc will redefine these to it's own implementation. It is safe
Index: include/usage.h
===================================================================
--- include/usage.h (revision 16163)
+++ include/usage.h (working copy)
@@ -2455,6 +2455,11 @@ USE_FEATURE_MDEV_CONFIG( \
#define reset_full_usage \
"Resets the screen."

+#define resize_trivial_usage \
+ ""
+#define resize_full_usage \
+ "Resizes the screen."
+
#define rm_trivial_usage \
"[OPTION]... FILE..."
#define rm_full_usage \
Index: include/applets.h
===================================================================
--- include/applets.h (revision 16161)
+++ include/applets.h (working copy)
@@ -226,6 +226,7 @@ USE_REALPATH(APPLET(realpath, _BB_DIR_US
USE_HALT(APPLET_ODDNAME(reboot, halt, _BB_DIR_SBIN, _BB_SUID_NEVER, reboot))
USE_RENICE(APPLET(renice, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RESET(APPLET(reset, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
+USE_RESIZE(APPLET(resize, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
USE_RM(APPLET(rm, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMDIR(APPLET(rmdir, _BB_DIR_BIN, _BB_SUID_NEVER))
USE_RMMOD(APPLET(rmmod, _BB_DIR_SBIN, _BB_SUID_NEVER))
Rich Felker
2006-09-21 18:04:13 UTC
Permalink
Post by Bernhard Fischer
Post by Rich Felker
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = TIMEOUT;
#endif
tcsetattr(0, TCSANOW, &new);
atexit(reset_to_old);
Using atexit() is not useful unless you call exit() from somewhere in
hmz. didn't i exit(ret)? no, i didn't. The whole alarm() can be canned
(i think) if TIMEOUT is used, perhaps. Didn't look closely.
Returning from main is an implicit exit so that's ok; my point was
that the atexit code will not automatically get called when you
receive a fatal signal. If you want to cleanup after fatal signals you
need to trap them.
Post by Bernhard Fischer
Post by Rich Felker
the program. Default fatal signal handlers cannot call atexit handlers
for you because they take place at the kernel level so you need to
handle them yourself if you want to.
Keep in mind that for static linking, atexit could add a lot of size
to the program too. So can scanf/printf. The program hardly uses stdio
as written and it should be easy to make it not depend on stdio at
all..
Well, but how would you output ROWS = \n COLUMNS = without outputting
anything?
IMO (and I seem recall someone else in the thread saying the same)
setting the variables is not a good idea anyway, so it's probably not
useful to print these.
Post by Bernhard Fischer
That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)
I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Yeah somewhere like that, I suppose. And if it's going in BB there's
no problem with using stdio, etc. since they'll already be linked
anyway. Avoiding them is only useful for tiny standalone programs.

Rich
Bernhard Fischer
2006-09-21 17:35:52 UTC
Permalink
Post by Rich Felker
/* Copyright 2006 Bernhard Fischer
* Licensed under GPLv2 or (at landleys or your opinion) any later version.
* Have fun or somesuch.
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <stdlib.h>
static struct termios old;
static void reset_to_old(void) {
tcsetattr(0, TCSANOW, &old);
}
int main(void) {
/* save_cursor_pos 7
* scroll_whole_screen [r
* put_cursor_waaaay_off [$x;$yH
* get_cursor_pos [6n
* restore_cursor_pos 8
*/
const char req[] = "\0337\033[r\033[999;999H\033[6n";
FILE *fp = fopen("/dev/stdin", "r+");
int f = fileno(fp);
Umm, this code is rather silly, and depends on /proc. Why not use
/dev/tty or if you really mean stdin, use fdopen(0)...?
STDIN_FILENO sounds like a better idea, yes.
Post by Rich Felker
struct winsize w = {0,0,0,0};
int ret;
struct termios new;
tcgetattr(0, &old); /* fiddle echo */
new = old;
new.c_cflag |= (CLOCAL | CREAD);
new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
#if defined(TIMEOUT) && (TIMEOUT >=1)
Should add a comment /* TIMEOUT in deciseconds */ and should default to
9 or the like..
Post by Rich Felker
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = TIMEOUT;
#endif
tcsetattr(0, TCSANOW, &new);
atexit(reset_to_old);
Using atexit() is not useful unless you call exit() from somewhere in
hmz. didn't i exit(ret)? no, i didn't. The whole alarm() can be canned
(i think) if TIMEOUT is used, perhaps. Didn't look closely.
Post by Rich Felker
the program. Default fatal signal handlers cannot call atexit handlers
for you because they take place at the kernel level so you need to
handle them yourself if you want to.
Keep in mind that for static linking, atexit could add a lot of size
to the program too. So can scanf/printf. The program hardly uses stdio
as written and it should be easy to make it not depend on stdio at
all..
Well, but how would you output ROWS = \n COLUMNS = without outputting
anything?

That's what you get if you write a quick, bloated hack for somebody
else, i guess ;)

I'm not even sure if something like this should go into busybox and
if so then where to put it. console-tools? miscutils?
/me fanciless ATM
Rich Felker
2006-09-21 17:38:18 UTC
Permalink
/* Copyright 2006 Bernhard Fischer
* Licensed under GPLv2 or (at landleys or your opinion) any later version.
* Have fun or somesuch.
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <stdlib.h>
static struct termios old;
static void reset_to_old(void) {
tcsetattr(0, TCSANOW, &old);
}
int main(void) {
/* save_cursor_pos 7
* scroll_whole_screen [r
* put_cursor_waaaay_off [$x;$yH
* get_cursor_pos [6n
* restore_cursor_pos 8
*/
const char req[] = "\0337\033[r\033[999;999H\033[6n";
FILE *fp = fopen("/dev/stdin", "r+");
int f = fileno(fp);
Umm, this code is rather silly, and depends on /proc. Why not use
/dev/tty or if you really mean stdin, use fdopen(0)...?
struct winsize w = {0,0,0,0};
int ret;
struct termios new;
tcgetattr(0, &old); /* fiddle echo */
new = old;
new.c_cflag |= (CLOCAL | CREAD);
new.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
#if defined(TIMEOUT) && (TIMEOUT >=1)
new.c_cc[VMIN] = 0;
new.c_cc[VTIME] = TIMEOUT;
#endif
tcsetattr(0, TCSANOW, &new);
atexit(reset_to_old);
Using atexit() is not useful unless you call exit() from somewhere in
the program. Default fatal signal handlers cannot call atexit handlers
for you because they take place at the kernel level so you need to
handle them yourself if you want to.

Keep in mind that for static linking, atexit could add a lot of size
to the program too. So can scanf/printf. The program hardly uses stdio
as written and it should be easy to make it not depend on stdio at
all..

Rich
Rob Landley
2006-09-20 23:49:33 UTC
Permalink
Post by Paul Fox
i agree, though one might come up with a mechanism that could be turned
on optionally by the calling program.
Actually, the correct place to do this is in bbsh when it's interactive.

Our existing terminal checking code should be taught about $LINES and
$COLUMNS, and should check them as a fallback for when the ioctl returns 0.
That's a small enough amount of bloat to be acceptable in exchange for the
functionality, it's basically atoi(getenv("LINES"))...

I added it (svn 16167). Dunno if it works, have to set up a test environment
that hasn't got a controlling terminal but has $LINES and $COLUMNS set...

Anyway, I can teach bbsh that when it's launched interactive, do the probing
thing if standard querying doesn't work to determine terminal size. That'll
set $LINES and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...

Rob
--
Never bet against the cheap plastic solution.
Bernhard Fischer
2006-09-21 17:13:20 UTC
Permalink
Post by Paul Fox
Post by Rob Landley
Who exactly are you testing the current size _from_? (Is your xterm
responding to the ansi escape sequence when it tries to display it?) If so,
ESC "7" ESC "[r" ESC "[999;999H" ESC "[6n"
ESC "[%d;%dR"
ESC "8"
Now that's about all one needs to know :)

The only inconvenient stuff is the termios flags for echo et. al.

Not really tested.. Can someone who initially faced the problem
give it a whirl, please?
TIA,

PS: before somebody asks for a "reset" applet, please consider using
either this alias or write a fancy script to that effect.

$ grep reset ~/.bashrc
# alias reset='echo -e '\''\033c'\'' ; stty sane line 1'

cheers,
Bernhard
Post by Paul Fox
the timeout on the read is long -- 10 seconds -- but it's a standalone
program, and can be killed if the terminal isn't responding.
Post by Rob Landley
I could just add this behavior as a config option to
get_terminal_width_height() in libbb (a fallback for when we get 0/0 as the
size). The hard part's figuring out when it's safe to do it. (Hmmm, poll
i agree, though one might come up with a mechanism that could be turned
on optionally by the calling program.
paul
=---------------------
paul fox, pgf at brightstareng.com
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resize.c
Type: text/x-csrc
Size: 1193 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060921/dbcc307b/attachment-0002.c
Paul Fox
2006-09-21 09:29:37 UTC
Permalink
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched
interactive, do the probing thing if standard querying
doesn't work to determine terminal size. That'll set $LINES
and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user
keystrokes already in the input buffer? The only way I can
think to avoid that is with some sort of tricky extra
buffering layer. Maybe it doesn't matter but I find it
annoying if I've typed ahead before a program starts and some
of the keystrokes get lost.
i agree. this certainly reinforces that this feature should be
very optional.

i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver. so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.

paul
=---------------------
paul fox, pgf at brightstareng.com
walter harms
2006-09-21 13:11:22 UTC
Permalink
sound good for me, where can i get it ? :)

re,
wh
Post by Paul Fox
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched
interactive, do the probing thing if standard querying
doesn't work to determine terminal size. That'll set $LINES
and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user
keystrokes already in the input buffer? The only way I can
think to avoid that is with some sort of tricky extra
buffering layer. Maybe it doesn't matter but I find it
annoying if I've typed ahead before a program starts and some
of the keystrokes get lost.
i agree. this certainly reinforces that this feature should be
very optional.
i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver. so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.
paul
=---------------------
paul fox, pgf at brightstareng.com
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Rob Landley
2006-09-21 19:56:15 UTC
Permalink
Post by Paul Fox
i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver.
It actually asks the driver first. (Well, the tty.) It resets $LINES and
$COLUMNS based on what the tty says if it gets a reasonable answer. If it
doesn't, it checks $LINES and $COLUMNS, and if that doesn't work either it
can try the ascii query thing (but only in interactive mode, when stdin and
stdout point to the same device, and only if there's no input waiting).
Post by Paul Fox
so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
The terminal wins.
Post by Paul Fox
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.
If you want to write one I'll review the patch, but I'm not doing it. (And
you can already set it in stty anyway.)

I can make the probing a config option if you want, though. Halfway planning
on that anyway (want to see how big it is when I'm done, terminal control is
already a config option in bbsh...)

Rob
--
Never bet against the cheap plastic solution.
walter harms
2006-09-21 13:11:22 UTC
Permalink
sound good for me, where can i get it ? :)

re,
wh
Post by Paul Fox
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched
interactive, do the probing thing if standard querying
doesn't work to determine terminal size. That'll set $LINES
and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user
keystrokes already in the input buffer? The only way I can
think to avoid that is with some sort of tricky extra
buffering layer. Maybe it doesn't matter but I find it
annoying if I've typed ahead before a program starts and some
of the keystrokes get lost.
i agree. this certainly reinforces that this feature should be
very optional.
i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver. so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.
paul
=---------------------
paul fox, pgf at brightstareng.com
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Rob Landley
2006-09-21 19:56:15 UTC
Permalink
Post by Paul Fox
i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver.
It actually asks the driver first. (Well, the tty.) It resets $LINES and
$COLUMNS based on what the tty says if it gets a reasonable answer. If it
doesn't, it checks $LINES and $COLUMNS, and if that doesn't work either it
can try the ascii query thing (but only in interactive mode, when stdin and
stdout point to the same device, and only if there's no input waiting).
Post by Paul Fox
so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
The terminal wins.
Post by Paul Fox
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.
If you want to write one I'll review the patch, but I'm not doing it. (And
you can already set it in stty anyway.)

I can make the probing a config option if you want, though. Halfway planning
on that anyway (want to see how big it is when I'm done, terminal control is
already a config option in bbsh...)

Rob
--
Never bet against the cheap plastic solution.
Paul Fox
2006-09-21 14:48:34 UTC
Permalink
Post by walter harms
sound good for me, where can i get it ? :)
i've put a copy of my stripped down resize.c at:
http://www.foxharp.boston.ma.us/tmp/small_resize.c
it can certainly be made smaller -- my goal was just to make
it readable for myself.

paul
Post by walter harms
Post by Paul Fox
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched
interactive, do the probing thing if standard querying
doesn't work to determine terminal size. That'll set $LINES
and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user
keystrokes already in the input buffer? The only way I can
think to avoid that is with some sort of tricky extra
buffering layer. Maybe it doesn't matter but I find it
annoying if I've typed ahead before a program starts and some
of the keystrokes get lost.
i agree. this certainly reinforces that this feature should be
very optional.
i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver. so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.
paul
=---------------------
paul fox, pgf at brightstareng.com
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
=---------------------
paul fox, pgf at brightstareng.com
Paul Fox
2006-09-25 12:22:57 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
No, but this would be the first x11 utility we'd added to the thing. At what
point do we suck in xvidtune? (Congratulations, you just convinced me that
it probably shouldn't go in.)
that's silly. resize never had anything to do with X11 in
the first place. i think perhaps no one else on this list even
knew resize existed until i brought it up last week, as solving a
problem which someone mentioned they'd had. it of course has
nothing in common with xvidtune. why do you insist on such
hyperbole?

=---------------------
paul fox, pgf at brightstareng.com
Rob Landley
2006-09-25 22:24:57 UTC
Permalink
Post by Paul Fox
Post by Rob Landley
Post by Bernhard Fischer
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
No, but this would be the first x11 utility we'd added to the thing. At what
point do we suck in xvidtune? (Congratulations, you just convinced me that
it probably shouldn't go in.)
that's silly. resize never had anything to do with X11 in
the first place.
man resize | tail -n 8
Reformatting resize(1), please wait...
AUTHORS
Mark Vandevoorde (MIT-Athena), Edward Moy (Berkeley)
Copyright (c) 1984, 1985 by X Consortium
See X(1) for a complete copyright notice.



X Window System RESIZE(1)
Post by Paul Fox
i think perhaps no one else on this list even
knew resize existed until i brought it up last week, as solving a
problem which someone mentioned they'd had.
Yup. And of course the first potential solution presented to any problem is
where all thinking on the matter must immediately stop.
Post by Paul Fox
it of course has
nothing in common with xvidtune. why do you insist on such
hyperbole?
Because I'm -> <- this close to walking away from the project entirely?

Bruce "bad penny" Perens somehow talked the SFLC into having a conference call
with me and him and Eric. I don't know why. The idea of having to deal with
that prima donna's incessant tantrums (when I'd thought _twice_ now that he'd
gone away for good) is stressing me out enough that I had headaches all
weekend and couldn't get to sleep until 5 am this morning. The man CREEPS ME
OUT.

I miss being a developer. I miss being able to spend as much time writing
code as reading it. I miss making purely technical judgements without having
to deal with politics. I miss seeing a problem and being able to focus on
_solving_ it. Being maintainer was never fun, but yesterday after dealing
with Bernhard in "small child demanding to help out in the kitchen" mode
(I.E. "I know nothing about shells, why won't you let me help with bbsh!?")
I really, really really wonder why I'm bothering.

I need to go do something else for a while.

Rob
--
Never bet against the cheap plastic solution.
Rob Landley
2006-09-25 22:24:57 UTC
Permalink
Post by Paul Fox
Post by Rob Landley
Post by Bernhard Fischer
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
No, but this would be the first x11 utility we'd added to the thing. At what
point do we suck in xvidtune? (Congratulations, you just convinced me that
it probably shouldn't go in.)
that's silly. resize never had anything to do with X11 in
the first place.
man resize | tail -n 8
Reformatting resize(1), please wait...
AUTHORS
Mark Vandevoorde (MIT-Athena), Edward Moy (Berkeley)
Copyright (c) 1984, 1985 by X Consortium
See X(1) for a complete copyright notice.



X Window System RESIZE(1)
Post by Paul Fox
i think perhaps no one else on this list even
knew resize existed until i brought it up last week, as solving a
problem which someone mentioned they'd had.
Yup. And of course the first potential solution presented to any problem is
where all thinking on the matter must immediately stop.
Post by Paul Fox
it of course has
nothing in common with xvidtune. why do you insist on such
hyperbole?
Because I'm -> <- this close to walking away from the project entirely?

Bruce "bad penny" Perens somehow talked the SFLC into having a conference call
with me and him and Eric. I don't know why. The idea of having to deal with
that prima donna's incessant tantrums (when I'd thought _twice_ now that he'd
gone away for good) is stressing me out enough that I had headaches all
weekend and couldn't get to sleep until 5 am this morning. The man CREEPS ME
OUT.

I miss being a developer. I miss being able to spend as much time writing
code as reading it. I miss making purely technical judgements without having
to deal with politics. I miss seeing a problem and being able to focus on
_solving_ it. Being maintainer was never fun, but yesterday after dealing
with Bernhard in "small child demanding to help out in the kitchen" mode
(I.E. "I know nothing about shells, why won't you let me help with bbsh!?")
I really, really really wonder why I'm bothering.

I need to go do something else for a while.

Rob
--
Never bet against the cheap plastic solution.
Dave Hylands
2006-09-19 02:54:11 UTC
Permalink
Hi,

I'm using busybox-1.1.2 under linux-2.6.17 on a gumstix.

When I run the vi from busybox over my serial line, it thinks that my
terminal is 80x24

My vi config options are set like this:
CONFIG_VI=y
CONFIG_FEATURE_VI_COLON=y
# CONFIG_FEATURE_VI_YANKMARK is not set
CONFIG_FEATURE_VI_SEARCH=y
CONFIG_FEATURE_VI_USE_SIGNALS=y
# CONFIG_FEATURE_VI_DOT_CMD is not set
# CONFIG_FEATURE_VI_READONLY is not set
# CONFIG_FEATURE_VI_SETOPTS is not set
# CONFIG_FEATURE_VI_SET is not set
CONFIG_FEATURE_VI_WIN_RESIZE=y
# CONFIG_FEATURE_VI_OPTIMIZE_CURSOR is not set

I dug through the code a bit to find the get_terminal_width_height function.

I then coded up a simple test program:

#include <stdio.h>
#include <termios.h>
#include <sys/ioctl.h>

int main( int argc, char **argv )
{
struct winsize win = { 0, 0, 0, 0 };
int ret = ioctl(fileno(stdin), TIOCGWINSZ, &win);

printf( "Width = %d, Height = %d\n", win.ws_col, win.ws_row );
return 0;
}

and when I run it, it reports 0 and 0 (which explains why
get_teminal_width_height reports 80x24).

If I ssh into the gumstix then running the above program reports the
correct size, and running vi works as expected.

My terminal type in both cases is vt100, and the TERM environment
variable is set appropriately.

So, is it possible to get the terminal size correct when using a serial port?

Any insight would be appreciated.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
Adam Hawes
2006-09-19 03:52:02 UTC
Permalink
Post by Dave Hylands
So, is it possible to get the terminal size correct when
using a serial port?
I don't believe it is. This works with SSH (and Telnet) because
ssh supports sending and receiving the terminal size from the client.
Serial consoles are dumb. They receive bits and echo them to the
terminal; VT100 ones at least.

You might be able to coax it into using ANSI terminal emulation
but you'd still need that on the serverb side.

Your best option is to work out your terminal size and configure
your environment accordingly when you log in - not that I know how
to do that. Most of my serial console work involves
'tail -f /var/log/messages'

A
Steven Scholz
2006-09-19 09:19:19 UTC
Permalink
Dave,
Post by Dave Hylands
So, is it possible to get the terminal size correct when using a serial port?
Any insight would be appreciated.
Is it an option for you the _set_ the terminal size using "stty rows" and
"stty cols" in some startup script?

--
Steven
Paul Fox
2006-09-19 10:05:13 UTC
Permalink
Post by Adam Hawes
Post by Dave Hylands
So, is it possible to get the terminal size correct when
using a serial port?
I don't believe it is. This works with SSH (and Telnet) because
ssh supports sending and receiving the terminal size from the client.
right. the best solution i've come up with is to use (a stripped down
version of) the "resize" program that i believe is, or was, distributed
with xterm. it uses an ansi query seqeunce to ask the terminal how
big it is, and then sets the tty driver's notion of the size correctly
based on that inforomation. always works reliably for me.

i have a feeling i may already have posted the code i'm using, or
a reference to it, to the list a while back. check the archives, or
ask me for a copy -- it's only a few pages long. for copyright
conflict reasons it can't become an applet, though it would be nifty if
someone would rewrite it so that it could be included in busybox.

paul
=---------------------
paul fox, pgf at brightstareng.com
Rob Landley
2006-09-19 16:49:18 UTC
Permalink
Post by Dave Hylands
Hi,
I'm using busybox-1.1.2 under linux-2.6.17 on a gumstix.
When I run the vi from busybox over my serial line, it thinks that my
terminal is 80x24
http://www.busybox.net/lists/busybox/2006-June/022850.html

As you discovered...
Post by Dave Hylands
If I ssh into the gumstix then running the above program reports the
correct size, and running vi works as expected.
Because ssh is setting up a pty.
Post by Dave Hylands
My terminal type in both cases is vt100, and the TERM environment
variable is set appropriately.
$TERM doesn't tell you size.
Post by Dave Hylands
So, is it possible to get the terminal size correct when using a serial port?
Any insight would be appreciated.
Try:

stty columns 80 rows 25

Rob
--
Never bet against the cheap plastic solution.
Paul Fox
2006-09-20 07:51:41 UTC
Permalink
Post by Rob Landley
Who exactly are you testing the current size _from_? (Is your xterm
responding to the ansi escape sequence when it tries to display it?) If so,
yes, exactly right. the code i have sends this:
ESC "7" ESC "[r" ESC "[999;999H" ESC "[6n"
then reads a response that looks like:
ESC "[%d;%dR"
and uses the results to feed TIOCSWINSZ. then send:
ESC "8"

the timeout on the read is long -- 10 seconds -- but it's a standalone
program, and can be killed if the terminal isn't responding.
Post by Rob Landley
I could just add this behavior as a config option to
get_terminal_width_height() in libbb (a fallback for when we get 0/0 as the
size). The hard part's figuring out when it's safe to do it. (Hmmm, poll
i agree, though one might come up with a mechanism that could be turned
on optionally by the calling program.

paul
=---------------------
paul fox, pgf at brightstareng.com
Paul Fox
2006-09-21 09:29:37 UTC
Permalink
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched
interactive, do the probing thing if standard querying
doesn't work to determine terminal size. That'll set $LINES
and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user
keystrokes already in the input buffer? The only way I can
think to avoid that is with some sort of tricky extra
buffering layer. Maybe it doesn't matter but I find it
annoying if I've typed ahead before a program starts and some
of the keystrokes get lost.
i agree. this certainly reinforces that this feature should be
very optional.

i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver. so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.

paul
=---------------------
paul fox, pgf at brightstareng.com
Paul Fox
2006-09-21 14:48:34 UTC
Permalink
Post by walter harms
sound good for me, where can i get it ? :)
i've put a copy of my stripped down resize.c at:
http://www.foxharp.boston.ma.us/tmp/small_resize.c
it can certainly be made smaller -- my goal was just to make
it readable for myself.

paul
Post by walter harms
Post by Paul Fox
Post by Rich Felker
Post by Rob Landley
Anyway, I can teach bbsh that when it's launched
interactive, do the probing thing if standard querying
doesn't work to determine terminal size. That'll set $LINES
and $COLUMNS for its child programs, and svn 16167 should
theoretically be able to take it from there...
How do you avoid eating (and possibly choking on) user
keystrokes already in the input buffer? The only way I can
think to avoid that is with some sort of tricky extra
buffering layer. Maybe it doesn't matter but I find it
annoying if I've typed ahead before a program starts and some
of the keystrokes get lost.
i agree. this certainly reinforces that this feature should be
very optional.
i'm a little surprised that rob thinks it should be in the shell.
in the absence of LINES and COLUMNS settings, programs that care
should all be asking the driver. so it doesn't have to be a
parent process that determines the size. in fact, if the parent
shell sets and exports LINES and COLUMNS, it seems like this will
only make it harder to deal with window size changes later on.
i'd vote for creating a separate applet (much like x11's resize)
which can be invoked manually or from .profile or wherever.
paul
=---------------------
paul fox, pgf at brightstareng.com
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
=---------------------
paul fox, pgf at brightstareng.com
Paul Fox
2006-09-25 12:22:57 UTC
Permalink
Post by Rob Landley
Post by Bernhard Fischer
Do you imply that you will rip out all of coreutils, findutils,
modutils, networking etc since you plan to write a shell that does
potentiall use them?!
No, but this would be the first x11 utility we'd added to the thing. At what
point do we suck in xvidtune? (Congratulations, you just convinced me that
it probably shouldn't go in.)
that's silly. resize never had anything to do with X11 in
the first place. i think perhaps no one else on this list even
knew resize existed until i brought it up last week, as solving a
problem which someone mentioned they'd had. it of course has
nothing in common with xvidtune. why do you insist on such
hyperbole?

=---------------------
paul fox, pgf at brightstareng.com
Continue reading on narkive:
Loading...