On Sun, Feb 28, 2010 at 4:31 AM, Xavier Chantry <[email protected]> wrote: > On Sun, Feb 28, 2010 at 10:24 AM, Roman Kyrylych > <[email protected]> wrote: >> On Sat, Feb 27, 2010 at 23:35, Xavier Chantry <[email protected]> >> wrote: >>> >>> Well Jeff and I are still waiting for some feedback on our original >>> questions.. >> >> Sorry for the delay. >> >> On Fri, Feb 26, 2010 at 22:39, Jeff <[email protected]> wrote: >>> Here is a simple POC to see what the output is. It calls ioctl twice >>> with a 10 second delay for changing window sizes between calls. It >>> doesn't use TIOCGSIZW as that is not defined in Linux, but rather BSD >>> and maybe some others. I am not familiar with vps or linode. >> >> So, I get >> rows: 0 >> columns: 0 >> rows: 0 >> columns: 0 >> instead of expected >> rows: 24 >> columns: 80 >> rows: 36 >> columns: 139 >> > > So TIOCGWINSZ is defined, the ioctl call does not return any error, > but it still just returns 0. Weird. > By the way, how did you figure out the expected values ? > > In git master, after the commit I linked above, with your bogus ioctl > call, or piping to cat, getcols() returns 0, and the callers treat > that as no linewrap. > So that could be a problem for you. I wonder if we should keep the > fallback to 80 columns in this bogus situation. > > Or maybe we could fallback to that old unused code : > - /* Original envvar way - prone to display issues > - const char *cenv = getenv("COLUMNS"); > - if(cenv != NULL) { > - return atoi(cenv); > > I am curious to know if that's the only way that works for you.
Honestly, why should we hack around terms that don't return valid values for us? Not wrapping seems perfectly reasonable in this situation. -Dan
