automated COL and WCOL settings

Gerard Beekmans gerard at
Tue Jul 17 08:51:11 PDT 2001

On Mon, Jul 16, 2001 at 09:47:18AM -0400, Gerard Beekmans wrote:
> On Fri, Jul 13, 2001 at 01:29:00PM +0200, Andre Wyrwa wrote:
> > stty size delivers terminal size as a string of the form "lines columns", cut gets the columns out of it.
> > We substract 10 from that value for COL and another 20 for WCOL.
> Not a bad idea. I've added it to Bugzilla so we can run some tests on
> this one to make sure it works ok and all that.

------- Additional Comments From Mark Hymers 2001-07-17 08:20 -------

I've tested this out with the following resolutions:

40x25 (no idea why this one is on my system - looks like an old bbc-b!)

There are two issues with this:

1) If we implement this, we need to move cut from /usr/bin to /bin as
lots of 
people won't have /usr mounted at the point at which we start using the
scripts.  I don't have a problem with this.

2) If you run scripts in xterm and konsole, it looks wierd.  I'd argue
that you shouldn't be running these scripts in xterms etc that often.

I think that the fact it looks a lot better at bootup and shutdown
these issues.

As usual, if there's no opposition in the next few days, I'll add this
to cvs 
(the change to textutils install to move cut and the change to the 
bootscripts).  Opinions please...

------- Additional Comments From Gerard Beekmans 2001-07-17 08:47

Moving cut would violate the FHS. People who are abiding to the FHS
won't be
able to use these boot scripts which isn't an option.

An alternative would be for the functions script to test for /bin/cut.
If it's
there, use the dynamic way of assigning a value to COL and WCOL. If
doesn't exist, then use the static values that we are using right now.

But this discussion should move to lfs-discuss as well. I'll forward a


Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list