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

Previous Next

Full log

Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-coreutils <at> gnu.org
Subject: Re: bug#25553: How many coreutils rely on tabs to align things (other, 
 than 'du'?
Date: Mon, 30 Jan 2017 19:56:47 -0800

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.

Previous Next

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