[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: |
Mon, 30 Jan 2017 19:56:47 -0800 |
User-agent: |
Thunderbird |
Paul Eggert wrote:
On 01/28/2017 10:13 PM, L A Walsh wrote:
This is already a problem
Of course. All I am saying is that we should not make it worse.
---
"Do as I say, not as I do?"
Wasn't 'ls' just change recently? You can come
up with arguments that it really wasn't made worse, but I
and others noticed it -- where as before, it wasn't
that noticeable, in part, because ls ***already*** has an
option to expand tabs in it that some have resorted to to
get reasonable output. It _does NOT_ have an option to
make use of a user's tab settings, nor does it have an option
to always generate the same output whether to a TTY or
a pipe/file.
Just as 'ls' already added options for user
control of color tab-expansion and such (up to a point --
still can't have it generate # of columns I want as it
reads those in from the TTY/Env), I'm adding the ability
to customize tab-usage on output.
you skirted the issue of using system-wide and per-user
config files which might also be used for similar purpose.
That's even worse. Coreutils doesn't do that now, thank goodness.
----
Well, on that I'm fine -- ENV vars are cleaner for
terminal settings anyway, but thought I'd offer an
alternative. ;-)
How can I send ls's default output through a filter
and have it be the same as to a TTY?
'ls -C'.
---
Doesn't work. I type 'ls' and get (abbreviated):
'[' id set-fields.c
b2sum id.c set-fields.h
basename.o join.o sha512sum
blake2 kill shred
cat kill.c shred.c
chcon.c libstdbuf.c shuf.o
chcon.o libstdbuf.so single-binary.mk
cp.c mknod sum
cp.o mknod.c sum.c
csplit mknod.o sum.o
csplit.o mktemp.c sync.c
cu-progs.mk mktemp.o sync.o
cut mv system.h
cut.c mv.c t
date nice tabout.c.000
date.o nice.o tabout.c.002
---
I type 'ls -C' and it doesn't look anything like that.
you didn't mention how the output would be re-encoded for a user's
tab settings on output
That could be the job of 'expand'. The user's tab settings can be
specified as arguments to 'expand'. If 'expand' doesn't have the desired
functionality now, perhaps we should improve 'expand'.
---
Expand would need to run in background and only apply
changes to output that is going to a user's terminal. If you
think that is possible I'd be happy to see/test/try it.
But we should not
be modifying every program to do expansion; just 'expand'. That's the
software tools design philosophy.
----
The various GNU and coreutil tools have mods in them
to support different user terminals as well as different
user languages (and locales) -- there is no generic filter done
to take program output and translate it on the fly -- it's built
into each program. But we **ARE NOT** talking piped or streamed
programs -- but ones that alter the 1-char=>1 space whether
to tty or file paradigm. They can't be filtered because they generate
non-linear output (1 char in = 1 char advanced on the TTY). Even
tabs don't really adhere to that as they go forward a variable amount
of spacing depending on what came before and how the output device
is setup to emulate tabs.
This is the same thing -- but like translations, can't
be done in a "post-filter" stage if for no other reason that
programs like 'ls' don't generate the same output to TTY's as
to 'filters'. There is no way for you to alter a general
purpose expansion program like 'entab' to show you a filtered
view of 'ls' because 'ls' generates different output to
the TTY vs. filters.
Even *if* the output was the same -- it is already the
case that the tools don't have the option for a user to
customize their output, say, to always expand tabs, or to
always use user-specified tabsizes.
The only solution to fix having different end-user-output
devices / languages was to provide a common interface or Terminal
API -- or to modify each program for translation into the the
number of tabs used in each users "locale". Currently, all of the
programs have some modifications for each end user's locale. Some
adapt to the users output device, if ONLY, in-so-much as adapting
to the user's TTY width.
I don't think all the programs need modification, but if
you really want to not touch all programs, then you are talking about
adding a library module to filter stdout & maybe stderr. But
having it work across all tools vs. a half-a-dozen is a very
different scope and amount of work.
I'm only proposing to "refilter" (retab)
a handful of programs -- and only if the user includes a switch
for that program. They can easily toss it into an alias and
forget about it -- and if the changes are in those programs, they
can be, optionally limited to only changing terminal output --
not pipe output.
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, L A Walsh, 2017/01/27
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, Paul Eggert, 2017/01/27
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, L A Walsh, 2017/01/27
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, Paul Eggert, 2017/01/28
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, L A Walsh, 2017/01/28
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, Paul Eggert, 2017/01/28
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, L A Walsh, 2017/01/29
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, Paul Eggert, 2017/01/30
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?,
L A Walsh <=
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, Paul Eggert, 2017/01/31
- bug#25553: How many coreutils rely on tabs to align things (other, than 'du'?, L A Walsh, 2017/01/31