[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25553: How many coreutils rely on tabs to align things (other, than

From: L A Walsh
Subject: bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?
Date: Sat, 28 Jan 2017 22:13:02 -0800
User-agent: Thunderbird

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]