From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eddie.starwolf.com (unknown [50.213.99.139]) by sourceware.org (Postfix) with ESMTP id 795173858C39 for ; Thu, 3 Feb 2022 09:59:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 795173858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=starwolf.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=starwolf.com Received: by eddie.starwolf.com (Postfix, from userid 118) id E650E55B3; Thu, 3 Feb 2022 01:59:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from valentina.serenity.starwolf.com (valentina.serenity.starwolf.com [172.21.12.7]) by eddie.starwolf.com (Postfix) with ESMTP id C347655B1; Thu, 3 Feb 2022 01:59:56 -0800 (PST) Subject: Re: ls -C broken To: L A Walsh , Thomas Wolff Cc: cygwin@cygwin.com References: <61FB4315.8040204@tlinx.org> From: Greywolf Message-ID: Date: Thu, 3 Feb 2022 01:59:56 -0800 User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <61FB4315.8040204@tlinx.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 09:59:59 -0000 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) >