* ls -C broken
@ 2022-01-28 15:46 Thomas Wolff
2022-01-28 16:11 ` [QUAR] " Eliot Moss
2022-02-03 2:51 ` L A Walsh
0 siblings, 2 replies; 4+ messages in thread
From: Thomas Wolff @ 2022-01-28 15:46 UTC (permalink / raw)
To: cygwin
If I redirect output of `ls -C` (file / pipe), it used to produce
well-formatted output in columns.
Suddenly it produces garbage formatting instead. As `ls` itself is not
new, maybe it's some library that breaks behaviour?
Or even pty code?? Works on Cygwin 32-bit. Any idea?
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [QUAR] ls -C broken
2022-01-28 15:46 ls -C broken Thomas Wolff
@ 2022-01-28 16:11 ` Eliot Moss
2022-02-03 2:51 ` L A Walsh
1 sibling, 0 replies; 4+ messages in thread
From: Eliot Moss @ 2022-01-28 16:11 UTC (permalink / raw)
To: Thomas Wolff, cygwin
On 1/28/2022 10:46 AM, Thomas Wolff wrote:
> If I redirect output of `ls -C` (file / pipe), it used to produce well-formatted output in columns.
> Suddenly it produces garbage formatting instead. As `ls` itself is not new, maybe it's some library
> that breaks behaviour?
> Or even pty code?? Works on Cygwin 32-bit. Any idea?
> Thomas
WJFFM in 64-bit on xterm and mintty. I am running Cygwin 3.3.3-1,
mintty 3.5.2-1, xterm 370-1, and ls 8.26-2.
Regards - EM
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ls -C broken
2022-01-28 15:46 ls -C broken Thomas Wolff
2022-01-28 16:11 ` [QUAR] " Eliot Moss
@ 2022-02-03 2:51 ` L A Walsh
2022-02-03 9:59 ` Greywolf
1 sibling, 1 reply; 4+ messages in thread
From: L A Walsh @ 2022-02-03 2:51 UTC (permalink / raw)
To: Thomas Wolff; +Cc: cygwin
On 2022/01/28 07:46, Thomas Wolff wrote:
> If I redirect output of `ls -C` (file / pipe), it used to produce
> well-formatted output in columns.
> Suddenly it produces garbage formatting instead. As `ls` itself is not
> new, maybe it's some library that breaks behaviour?
> Or even pty code?? Works on Cygwin 32-bit. Any idea?
> Thomas
>
---
The authors of Gnu ls changed 'ls' defaults because "they can".
Old ls -C:
/bin/ls /proc
331 379 913 filesystems mounts registry32 swaps version
332 500 cpuinfo loadavg net registry64 sys
335 731 cygdrive meminfo partitions self sysvipc
new ls -C:
/bin/ls /proc|cat
331
332
335
370
379
500
731
732
945
946
cpuinfo
cygdrive
devices
filesystems
loadavg
meminfo
misc
mounts
net
partitions
registry
registry32
registry64
self
stat
swaps
sys
sysvipc
uptime
version
---
with column:
law.Bliss> /bin/ls /proc|column (tabs mismatch)
331 731 devices net stat
332 732 filesystems partitions swaps
335 952 loadavg registry sys
370 953 meminfo registry32 sysvipc
379 cpuinfo misc registry64 uptime
500 cygdrive mounts self version
with column+expand -8:
s> /bin/ls /proc|column|expand -8
1021 379 devices net stat
1022 500 filesystems partitions swaps
331 731 loadavg registry sys
332 732 meminfo registry32 sysvipc
335 cpuinfo misc registry64 uptime
370 cygdrive mounts self version
---
several other tools no longer have settings to expand tabs to user-values
requiring the use of expand.
Formats of numeric output were also changed, requiring usage of 'numfmt'
This was all done to benefit script consistency at the expense of
users usability. It is expected that users can adapt to the computers.
by default, 'ls' will produce different output when it goes to the
screen vs. when
it goes to a pipe. When 'ls' goes to a pipe it is required to only use
1 column.
To get the behavior you want, try piping through 'column' first (see
'man (1) column).
They made many changes in core-utils to make automated shell scripts more
consistent at the expense of user-usability where they now suggest using
pipes into other utilities to get previous output
Try using ls|column. Of course ls also used to expand tabs to every 8
characters
and it no longer does that. So you must use another util 'tabs' to set
tabs to every
8th column (ls's standard tab setting)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ls -C broken
2022-02-03 2:51 ` L A Walsh
@ 2022-02-03 9:59 ` Greywolf
0 siblings, 0 replies; 4+ messages in thread
From: Greywolf @ 2022-02-03 9:59 UTC (permalink / raw)
To: L A Walsh, Thomas Wolff; +Cc: cygwin
That would be rude on the part of GNU, that's for sure.
Below, though, I don't see the use of -C explicitly. ls defaults to -C if
output is to a terminal, and to -1 if not, as it has done for many years.
I see a lot of red herrings in the explanations below as regarding column,
tabs, expand, and numfmt. I don't think any of them come into play
Which version of 'ls' is pulling this nonsense?
On 2/2/22 6:51 PM, L A Walsh wrote:
> On 2022/01/28 07:46, Thomas Wolff wrote:
>> If I redirect output of `ls -C` (file / pipe), it used to produce
>> well-formatted output in columns.
>> Suddenly it produces garbage formatting instead. As `ls` itself is not
>> new, maybe it's some library that breaks behaviour?
>> Or even pty code?? Works on Cygwin 32-bit. Any idea?
>> Thomas
>>
> ---
> The authors of Gnu ls changed 'ls' defaults because "they can".
> Old ls -C:
> /bin/ls /proc
Where is the -C?
> 331 379 913 filesystems mounts registry32 swaps version
> 332 500 cpuinfo loadavg net registry64 sys
> 335 731 cygdrive meminfo partitions self sysvipc
> new ls -C:
> /bin/ls /proc|cat
Where is the -C?
> 331
> 332
> 335
> 370
> 379
> 500
> 731
> 732
> 945
> 946
> cpuinfo
> cygdrive
> devices
> filesystems
> loadavg
> meminfo
> misc
> mounts
> net
> partitions
> registry
> registry32
> registry64
> self
> stat
> swaps
> sys
> sysvipc
> uptime
> version
> ---
> with column:
> law.Bliss> /bin/ls /proc|column (tabs mismatch)
> 331 731 devices net stat
> 332 732 filesystems partitions swaps
> 335 952 loadavg registry sys
> 370 953 meminfo registry32 sysvipc
> 379 cpuinfo misc registry64 uptime
> 500 cygdrive mounts self version
> with column+expand -8:
> s> /bin/ls /proc|column|expand -8
> 1021 379 devices net stat
> 1022 500 filesystems partitions swaps
> 331 731 loadavg registry sys
> 332 732 meminfo registry32 sysvipc
> 335 cpuinfo misc registry64 uptime
> 370 cygdrive mounts self version
> ---
> several other tools no longer have settings to expand tabs to user-values
> requiring the use of expand.
> Formats of numeric output were also changed, requiring usage of 'numfmt'
> This was all done to benefit script consistency at the expense of
> users usability. It is expected that users can adapt to the computers.
> by default, 'ls' will produce different output when it goes to the
> screen vs. when
> it goes to a pipe. When 'ls' goes to a pipe it is required to only use
> 1 column.
Not strictly "required" but has done since forever.
> To get the behavior you want, try piping through 'column' first (see
> 'man (1) column).
>
> They made many changes in core-utils to make automated shell scripts more
> consistent at the expense of user-usability where they now suggest using
> pipes into other utilities to get previous output
GNU is getting too big for their britches. This is completely out of line.
> Try using ls|column. Of course ls also used to expand tabs to every 8
> characters
> and it no longer does that. So you must use another util 'tabs' to set
> tabs to every 8th column (ls's standard tab setting)
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-02-03 9:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-28 15:46 ls -C broken Thomas Wolff
2022-01-28 16:11 ` [QUAR] " Eliot Moss
2022-02-03 2:51 ` L A Walsh
2022-02-03 9:59 ` Greywolf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).