On 9/19/22 20:19, galih surya wrote:
Actually, I don't know if this is a bug.
It's not something 'ls' can easily fix, because 'ls' can't deduce from
the operating system that you have installed nonstandard tab stops.
I installed the attached to try to document the issue.
Messing with hardware tab stops is typically more trouble than it's
worth. I think the last time I did it was back in the 1970s, with a IBM
029 keypunch drum card. Back then it sort of made sense, if you were
programming in assembler or FORTRAN 66. Nowadays, not so much.From 4cbe227fa0b1bfd05b10245a3466ed99413e3a15 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 20 Sep 2022 00:09:42 -0700
Subject: [PATCH] doc: warn about tabs command (bug#57946)
---
doc/coreutils.texi | 9 +
1 file changed, 9 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index e6eae44dc..adf957e61 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8295,6 +8295,15 @@ TAB following a non-ASCII byte. You can avoid that issue by using the
@option{-T0} option or put @code{TABSIZE=0} in your environment, to tell
@command{ls} to align using spaces, not tabs.
+If set a terminal's hardware tabs to anything other than the default,
+you should also use a @command{--tabsize} option or @env{TABSIZE}
+environment variable either to match the hardware tabs, or to disable
+the use of hardware tabs. Otherwise, the output of @command{ls} may
+not line up. For example, if you run the shell command @samp{tabs -4}
+to set hardware tabs to every four columns, you should also run
+@samp{export TABSIZE=4} or @samp{export TABSIZE=0}, or use the
+corresponding @option{--tabsize} options.
+
@item -w @var{cols}
@itemx --width=@var{cols}
@opindex -w
--
2.37.3
