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