Subject: bug#46060: closed (Re: bug#46060: Offer ls --limit=...)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 25 Jan 2021 06:49:02 +0000

Your bug report

#46060: Offer ls --limit=...

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
46060: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46060
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#46060: Offer ls --limit=...
From: 積丹尼 Dan Jacobson <[email-masked]>
To: Paul Eggert <[email-masked]>
Cc: [email-masked]
Date: Mon, 25 Jan 2021 14:48:13 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

>>>>> "PE" == Paul Eggert <[email-masked]> writes:
PE> That argument would apply to any program, no? "cat", "diff", "sh",
PE> "node",....

PE> Not sure why "ls" needs a convenience flag that would complicate the
PE> documentation and maintenance and be so rarely useful.

OK, then I'll close the bug then.

Subject: Offer ls --limit=...
From: 積丹尼 Dan Jacobson <[email-masked]>
To: [email-masked]
Date: Sun, 24 Jan 2021 05:13:17 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

I hereby propose "ls --limit=..."

$ ls --limit=1 # Would only print one result item:
A

You might say:
"Jacobson, just use "ls|sed q". Closed: Worksforme."

Ah, but I am talking about items, not lines:

$ ls
A  B  C  D
E  F  G  H
I  J  K  L
$ ls -C|sed 2q
A  B  C  D
E  F  G  H
$ ls -C --limit=2
A        B
$ ls    --limit=2
A        B

Indeed, directories might be huge. And any database command already has
a --limit option these days, and does not rely on a second program to
trim its output because it can't control itself. Indeed, on some remote
connections one would only want to launch one program, not two. Thanks.