On Thursday July 23 2009, David C. Rankin wrote:

On Thursday 23 July 2009 09:43:12 pm David C. Rankin wrote:

...

On Thursday 23 July 2009 09:22:34 pm David C. Rankin wrote:

...

Listmates,

OK,

When did "LINES" and "COLUMNS" stop being exported?

If openSuSE isn't exporting "LINES" and "COLUMNS" anymore, there will be a whole bunch of bash programming guide examples that no longer work. Let me know if someone else can confirm this and I will write the bug report. Which package would cause this behavior to change??

% vq COLUMN COLUMNS=180 % % eq COLUMN % Vq and eq are "variable query" and "environment query": vq () { set | egrep -e "$1"; } eq () { export | sed -n -e "/$1/ s/declare -x //p"; }

-- David C. Rankin

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday July 23 2009, David C. Rankin wrote:

On Thursday 23 July 2009 10:13:00 pm Randall R Schulz wrote:

...

...

Randall,

I kind of follow you here. Are you saying that I need to do both queries in each script to determine if the proper environment or variable parameters? What I was getting at is that I have used LINES & COLUMNS in scripts in the past that relied on both but didn't have to alter the environment. Why are these needed now?

I only meant to give you a data point per your request. The vq and eq procedures are generic and I use them quite a lot, though not that I can recall for COLUMNS. You can always just put an export command in your .bash_profile or .login file (I can never keep straight which you use for what but .bashrc will always work, of course, even though it's highly redundant to do so for environment variables). Anyway, I don't know if COLUMNS is updated when the terminal size is changed. I do know that the stty output is always current. I have another script for that, "tsize": -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- #!/bin/bash --norc rowsOnly= colsOnly= for arg; do case "$arg" in -r | --row | --rows) rowsOnly=1 colsOnly= ;; -c | --col | --cols) colsOnly=1 rowsOnly= ;; esac done stty -a \ |( if [ $rowsOnly ]; then sed -rn '/rows/ s/.*rows +([^;]+);.*/\1/p' elif [ $colsOnly ]; then sed -rn '/columns/ s/.*columns +([^;]+);.*/\1/p' else sed -rn '/rows.*columns/ s/.*(rows[^;]+;[^;]+);.*/\1/p' fi ) -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- % tsize rows 97; columns 180 It can easily be modified to output a COLUMNS (or ROWS) -setting command, of course.

-- David C. Rankin

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 23 July 2009 11:33:00 pm Randall R Schulz wrote:

On Thursday July 23 2009, Randall R Schulz wrote:

...

...

% tsize rows 97; columns 180

Thanks, stty is a handy little command. Yes, LINES & COLUMNS is aways current, so they must be set based on stty after each terminal resize. I like staying away from manually exporting variables in the init scripts for later use in scripts -- just to keep the scripts somewhat reusable by someone else. If I started exporting things and relying on them, no question -- I would forget over time which were specifically exported and which were accessible. I'll pull from stty and see how that goes. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday July 23 2009, David C. Rankin wrote:

...

OK,

This is it!

#!/bin/bash --norc tmp=$(stty -a) tmp=${tmp##*rows\ } rows=${tmp%%;*} tmp=${tmp##*columns\ } cols=${tmp%%;*} echo "rows: $rows; cols: $cols"

Now it they just don't change the output format of stty -a....

There is a generalized substitution variant of the variable expansion syntax that is a that can strip content from around (from both sides) in a single expansion. That would clean up the foregoing code.

-- David C. Rankin

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David C. Rankin wrote:

On Friday 24 July 2009 08:19:24 am Randall R Schulz wrote:

...

...

#!/bin/bash --norc tmp=$(stty -a) tmp=${tmp##*rows\ } rows=${tmp%%;*} tmp=${tmp##*columns\ } cols=${tmp%%;*} echo "rows: $rows; cols: $cols"

Now it they just don't change the output format of stty -a....

There is a generalized substitution variant of the variable expansion syntax that is a that can strip content from around (from both sides) in a single expansion. That would clean up the foregoing code.

Hmm, I'll have to wade the frigid waters of man bash again...

I must have missed something. Why do you think these values are not exported? You do realize that lines & columns are dynamic values which at least some terminals and login daemons will continuously adjust right? de1:~ # echo $LINES $COLUMNS 25 80 de1:~ # echo $LINES $COLUMNS 29 86 de1:~ # sh de1:~> echo $LINES $COLUMNS 29 86 de1:~> cat /etc/SuSE-release openSUSE 11.1 (x86_64) VERSION = 11.1 de1:~> What the above shows is that I dragged the corner of my PuTTY window (which was connected to sshd, not every terminal client nor every server daemon does this) making the window a little larger and without issuing any commands, and no possibility that any bashrc or inclusions got executed, the values changed, because the terminal told the daemon and the daemon told it's child processes. Spawning a new shell creates a new seperate child process, and the values are still present, which proves that they were exported. I had not changed the window size so they weren't set anew, they had to have been exported to be present at all. Finally that this was an opensuse 11.1 box. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 24 July 2009 06:13:55 pm Brian K. White wrote:

I must have missed something. Why do you think these values are not exported? You do realize that lines & columns are dynamic values which at least some terminals and login daemons will continuously adjust right?

de1:~ # echo $LINES $COLUMNS 25 80 de1:~ # echo $LINES $COLUMNS 29 86 de1:~ # sh de1:~> echo $LINES $COLUMNS 29 86 de1:~> cat /etc/SuSE-release openSUSE 11.1 (x86_64) VERSION = 11.1 de1:~>

What the above shows is that I dragged the corner of my PuTTY window (which was connected to sshd, not every terminal client nor every server daemon does this) making the window a little larger and without issuing any commands, and no possibility that any bashrc or inclusions got executed, the values changed, because the terminal told the daemon and the daemon told it's child processes. Spawning a new shell creates a new seperate child process, and the values are still present, which proves that they were exported. I had not changed the window size so they weren't set anew, they had to have been exported to be present at all. Finally that this was an opensuse 11.1 box.

Brian, Try calling them from within a script: #!/bin/bash echo "My Lines: $LINES & My Columns: $COLUMNS" exit 0 That's what got us started... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David C. Rankin wrote:

On Friday 24 July 2009 06:13:55 pm Brian K. White wrote:

...

I must have missed something. Why do you think these values are not exported? You do realize that lines & columns are dynamic values which at least some terminals and login daemons will continuously adjust right?

de1:~ # echo $LINES $COLUMNS 25 80 de1:~ # echo $LINES $COLUMNS 29 86 de1:~ # sh de1:~> echo $LINES $COLUMNS 29 86 de1:~> cat /etc/SuSE-release openSUSE 11.1 (x86_64) VERSION = 11.1 de1:~>

What the above shows is that I dragged the corner of my PuTTY window (which was connected to sshd, not every terminal client nor every server daemon does this) making the window a little larger and without issuing any commands, and no possibility that any bashrc or inclusions got executed, the values changed, because the terminal told the daemon and the daemon told it's child processes. Spawning a new shell creates a new seperate child process, and the values are still present, which proves that they were exported. I had not changed the window size so they weren't set anew, they had to have been exported to be present at all. Finally that this was an opensuse 11.1 box.

Brian,

Try calling them from within a script:

#!/bin/bash echo "My Lines: $LINES & My Columns: $COLUMNS" exit 0

That's what got us started...

Ok lets put this silliness to rest. Don't take this as negatively as it sounds but I think this is a red herring waste of time chasing nothing. I didn't happen to know everything about the history and design goals of the $LINES and $COLUMNS convention either before you raised the question (still don't). But I did know that it has never been a problem and in almost 20 years of xenix/unix/linux/bsd poking both for work & play I only extremely rarely came across an app that even cared about those variables, and only extrememly extremely rarely ever had an actual problem with such an app, so, it was such a non-issue it never warranted an in depth look. The one actual problem I can point at actually is opensuse's profile/bashrc scripts that detect serial consoles and borkenly set 80x24, and keep resetting it in bashrc, and thus break curses mode yast by making some parts of the yast unreachable, making it a pain to do text mode installs via serial console. But just in the interest of stopping this retarded circus of the blind leading the blind in here, I simply took a look around at as many different types of systems as I could quickly lay my hands on. The result? I do duplicate your results on opensuse 11.1. However, I also duplicate them on 11.0, 10.3, 10.2, 10.1, 10.0, 9.3, and 9.0, Ubuntu 9.04, FreeBSD 8, and OSX 10.4 ppc. Solaris 9 sparc doesn't even set them in the first place let alone export them. In fact the only place I do see what you expect is on SCO Open Server 5.0.6 & 5.0.7 (which I can tell you will also mean the same on basically everything going back to Xenix). I have only infrequent and inconvenient access to an HPUX and an AIX machine so I didn't test those, but sometime I can. What I did exactly, and the same on every box, was: Log in with a user whose login shell is a bourne variant, and manually ran: set |egrep "(LINES|COLUMNS)" And then the same in a script: # cat fff #!/bin/sh set |egrep "(LINES|COLUMNS)" # chmod 755 fff # ./fff # And in all cases but the two exceptions already noted, the variables were both present and set to non-empty values there in the login session, but in the script they were absent, not merely present and set to empty, but not present at all. (Thats the point of using set or env instead of echo, to tell the different between empty and unset) Of the 2 exceptions, only one exports the variables to the script. So I submit that the error is in expecting something other than what most servers do today and have been doing for years as well. Although, I would also actually be perverse and say that since the SCO systems predate most others, including ALL linux, that you could actually make the argument that the dwindling remaining production sco boxes in the world are right and the 90 million linux & freebsd & sun boxes are all wrong. But the weight of numbers beats the weight of seniority in the real world, so whatever script you have that expects behavior that no linux box exhibits, is simply a broken script exactly for that reason. Or, instead of calling it broken call it simply a user/usage requirement, it expects you to tend to those variables yourself just like any other usage requirement of any other script or app. Or, perhaps it's simply not a portable script. Plenty of scripts and applications written for SCO will use a variable $LPDEST because on sco that is the variable a user sets to define their default printer. Such scripts and apps don't work on Linux out of the box because linux pays no attention to LPDEST but instead uses PRINTER for that purpose. The linux boxes aren't all broken even though LPDEST predates them. Nor are the scripts, really. They just need porting to Linux or any other platform before they work anywhere else. Also of course there are many potential variables (as in conditions, not shell environment variables) which I did not describe here or perform exactly the same in every case which could have affected these results, so it's not rigorously scientific, but I'm satisfied with the overall point. The differences are things like, sometimes the login daemon was the stock legacy telnetd, openssh sshd, getty, or X. Sometimes the terminal (client) was putty, the telnet or ssh client on some other box, the hardware text vga console, or xterm on the console. Sometimes the shell was bash, sysv/at&t sh, bsd sh, or ksh. This is actually good because, if say the login issuer were always openssh, then perhaps the consistency was a result of a quirk of openssh and not actually a common feature across the various systems? In other words, hope you didn't submit a bug report describing standard system behavior as a bug. ;) -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Hello, On Thu, 23 Jul 2009, Randall R Schulz wrote: [snippetry] A somewhat inelegant approach, for my taste, and if I may say so ;) ==== (Note: my sed has no '-r') ==== #!/bin/bash --norc ttyinfo="$(stty -a)" for arg; do case "$arg" in -r|--r*) echo "$ttyinfo" | sed -n '/rows/ s/.*rows \+\([^;]\+\);.*/\1/p'; continue ;; -c|--c*) echo "$ttyinfo" | \ sed -n '/columns/ s/.*columns \+\([^;]\+\);.*/\1/p'; continue ;; esac done if test "$#" -eq 0; then echo "$ttyinfo" | \ sed -n '/rows.*columns/s/.*\(rows[^;]\+;[^;]\+\);.*/\1/p' fi ==== That way, you can even use '-r' and '-c' together without getting logically inconsistent, if you reinterpret -r / -c as 'give me rows' and 'give me columns' and still call stty only once ;) Of course, you could also use awk similar to below instead of sed. With a different output-format, done as a function for easy copy and paste: ==== #!/bin/bash --norc termsize() { stty -a | awk ' BEGIN { RS=";"; FS=" "; } $1 ~ /rows|columns/ { ### or: $1 == "rows" || $1 == "columns" # [*] sub("rows", "LINES", $1); printf("%s=%s\n", toupper($1), $2); } ' } termsize # eval "$(termsize)" ### [*] no idea what is faster in awk, the regex-match or the ### two string comparisons. ==== Its output can be eval'd (as commented), and an 'export ' could be added to the printf. Otherwise you could just comment the sub() line. One could also make the exporting into an option to the function. BTW: LINES and COLUMNS are not exported here on an ex-SUSE 6.2. (0)$ grep COLUMN /proc/$$/environ (1)$ env | grep COLUMN (1)$ set | grep COLUMN COLUMNS=81 (0)$ HTH, -dnh -- If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc. -- RfC 3514 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-07-23 at 22:01 -0500, David C. Rankin wrote:

[21:58 alchemy:/home/david] # grep COLUMNS /etc/* /etc/profile: export LINES COLUMNS TERM

There is an "if" before that which nullifies the command, I think. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpsOMYACgkQtTMYHG2NR9XCIQCbBGFV3P+WTJhWLIFBMy5XZ/o5 aJkAn356JQBTxLL3si0ZDplLsVy3vywF =qmOJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org