ls -C broken

ls -C broken

[Thomas Wolff]

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

Re: [QUAR] ls -C broken

[Eliot Moss]

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

Re: ls -C broken

[L A Walsh]

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)

Re: ls -C broken

[Greywolf]

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)
>