GNU bug report logs - #46060
Offer ls --limit=...

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46060 in the body.
You can then email your comments to 46060 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-coreutils <at> gnu.org
Subject: Offer ls --limit=...
Date: Sun, 24 Jan 2021 05:13:17 +0800

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.

Message #8 received at 46060 <at> debbugs.gnu.org (full text, mbox):

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 46060 <at> debbugs.gnu.org
Subject: Re: bug#46060: Offer ls --limit=...
Date: Sun, 24 Jan 2021 12:14:44 +0100

Hi Dan,

On 23.01.21 22:13, 積丹尼 Dan Jacobson wrote:
> 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:

You can use the ls option '-1' to print one item per line:

    $ touch {a..z}
    $ ls -1 | head -n8
    a
    b
    c
    d
    e
    f
    g
    h

You can use 'column' (from package "bsdmainutils" in Debian etc.)
to columnate the result:

    $ ls -1 | head -n8 | column
    a       b       c       d       e       f       g       h

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

It might be nice not to have to create all the output that is to be
discarded, especially on remote and/or slow file systems.

The one program requirement could be fulfilled by a script or shell
function.

I am sorry if my email hinders possible acceptation of an implementation
of your suggestion, but I did want to show that there is a workaround
(adding non-GNU software to the mix, though).

Thanks,
Erik

Message #11 received at 46060 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
Cc: 46060 <at> debbugs.gnu.org
Subject: Re: bug#46060: Offer ls --limit=...
Date: Sun, 24 Jan 2021 19:54:12 +0800

Sure, it is against the https://en.wikipedia.org/wiki/Unix_philosophy, but
just like SQL has LIMIT,
and
$ unicode --help
  -m MAXCOUNT, --max=MAXCOUNT
                        Maximal number of codepoints to display...

Just like "we want to stop pollution at the source", not always "clean up after it".

Message #14 received at 46060 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
Cc: 46060 <at> debbugs.gnu.org
Subject: Re: bug#46060: Offer ls --limit=...
Date: Sun, 24 Jan 2021 19:57:21 +0800

E.g.,
"What is API pagination? Some APIs, such as Contacts can return millions
of results. We obviously can't return all of them at once, so we need to
return a subset - or a page - at a time. This technique is called paging
and is common to most APIs. Paging can be implemented in many different
ways, some better than others."
Anyway, this ls command was built in the early years of computer science...

Message #17 received at 46060 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 46060 <at> debbugs.gnu.org
Subject: Re: bug#46060: Offer ls --limit=...
Date: Sun, 24 Jan 2021 12:13:18 -0800

On 1/23/21 1:13 PM, 積丹尼 Dan Jacobson wrote:
> 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.

That argument would apply to any program, no? "cat", "diff", "sh", 
"node",....

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

Message #22 received at 46060-done <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 46060-done <at> debbugs.gnu.org
Subject: Re: bug#46060: Offer ls --limit=...
Date: Mon, 25 Jan 2021 14:48:13 +0800

>>>>> "PE" == Paul Eggert <eggert <at> cs.ucla.edu> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.