GNU bug report logs - #25553
How many coreutils rely on tabs to align things (other, than 'du'?

Previous Next

Full log

View this message in rfc822 format

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 25553 <at> debbugs.gnu.org
Subject: bug#25553: How many coreutils rely on tabs to align things (other,  than 'du'?
Date: Sat, 28 Jan 2017 22:13:02 -0800

Paul Eggert wrote:
> L A Walsh wrote:
>>     The idea would be to have it be transparent. Adding
>> on various output filters is hardly transparent.
> 
> Nor is having behavior depend on environment variables.
---
	The behavior isn't dependent on environment variables.
The behavior is selected by the run-time switch values.

	The run-time switch, like ls's --color flag get color
values from LS_COLORS (which came from the user's TERM settings).
There, you have core utils relying on a 2nd ENV var to cache the
results of the 1st (TERM) env var.



>>     As for env-vars.  What problems are you envisioning.
> 
> Shell scripts might stop working because the environment variables are 
> not set up in the usual or desired way.
---
	This is already a problem with functions and aliases as well
as PATH differences.  Though, for that matter, scripts *RELY* 
on environment variables already.  This usage could conceivable be
no different than the case of 'ls' altering its screen output if
output is not used in a script.  How would that not address your concern?


> This is a common problem with 
> other environment variables. In the past, we've relied on the 
> environment too often for relatively-unimportant things. We should not 
> repeat this mistake.
----
	I've never had the problem, but what mistakes are you claiming
were made by use of environment variables for TERMinal settings, character
set settings or language settings?  In fact, doesn't gnu make heavy use
of LC_specific variables -- and would fail miserably in localization if
those variables were disallowed?

	You can't argue that there are no valid uses for ENV vars.
At the same time, you skirted the issue of using system-wide and per-user
config files which might also be used for similar purpose.



>>     As for 'expand' handling the job -- how would
>> expand convert tabstops from 'du' into the tabstops used by
>> an arbitrary terminal?  For that matter, since directory and
>> file sizes often exceed 8-characters forcing du's output to not align, 
>> how can a user have 'du' align it's columns
>> automatically, as my additions can do?
> 
> Send du's output to a file,
----

	And if the program doesn't generate the same output
to a file as to a 'TTY'?  However, this is for TTY-output 
devices -- it's not intended for inter-program communications.
In fact, as you point out, that should likely be excluded by default.  

	You mention 'ls' -- as an example of another tab-using
program.  How can I send ls's default output through a filter
and have it be the same as to a TTY?  By default -- one can't.
The same happens for users of Gnu's libc.  It, also dumps output 
to a terminal that, by default, is not redirectable. 



> look for the longest number in the file, and 
> adjust column width accordingly. Whatever tabstops you like, you can 
> tell to 'expand'. Expanding tabs is the job of 'expand', not of every 
> program that outputs tabs.
----
	Expanding tabs, for *some* gnu programs, could be done w/expand, 
but you didn't mention how the output would be re-encoded for a user's
tab settings on output, not to mention how you would redirect
'ls's output through a filter or to a file to any effect.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.