bugfindutils - Bugs: bug #55095, please add "--count" to...

 
 

bug #55095: please add "--count" to find

Submitted by:  Harald Dunkel <harri>
Submitted on:  Sun 25 Nov 2018 04:14:11 PM UTC  
 
Category:  find Severity:  1 - Wish
Item Group:  None Status:  Wont Fix
Privacy:  Public Assigned to:  Bernhard Voelker <berny>
Originator Name:  Open/Closed:  Closed
Release:  4.6.0 Fixed Release:  None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 09 Jan 2019 12:54:39 PM UTC, comment #9:

Considering the answers of Bob and Andreas, and the conflicting issue pointed out by myself, I'm closing this as WONTFIX.

Thanks & have a nice day,
Berny

Bernhard Voelker <berny>
Project AdministratorIn charge of this item.
Mon 26 Nov 2018 11:05:05 PM UTC, comment #8:

I'm also getting differences for $HOME between 'find' and 'du', but this
is because 'du' doesn't output duplicate files, i.e., hardlinks.
Well, this is quite unrelated to requesting -count as new find action.

Bernhard Voelker <berny>
Project AdministratorIn charge of this item.
Mon 26 Nov 2018 05:23:09 PM UTC, comment #7:

The "find -printf ." is surely an improvement, but using it on my $HOME it still writes appr 300K on stdout to be read by wc, instead of "302221".

Harald Dunkel <harri>
Mon 26 Nov 2018 04:00:36 PM UTC, comment #6:

What do you refer to? I mean it's quite obvious that the implicit
-print will output 2 lines for a file with a newline in its name.
That's why I'd use "-printf ." instead (no fiddling with the names
at all).

Bernhard Voelker <berny>
Project AdministratorIn charge of this item.
Mon 26 Nov 2018 01:56:15 PM UTC, comment #5:

% cd /tmp
% rm -f sample*
% touch "sample
> 42"
% find sample* | wc -l
2

Harald Dunkel <harri>
Mon 26 Nov 2018 08:48:27 AM UTC, comment #4:

It is not as easy as 'i++', what about the interference
with other options, e.g.:

$ find . \( -name NAMEONE -quit \) -o \( -name NAMETWO -count \)

In that case, the -count action would not be performed if NAMEONE
was found first by chance. The command following this would certainly
be quite surprised.

FWIW: my favorite for the general case is (although it needs a pointless stat()):
$ find .... -printf '.' | wc

or, if no other tests/conditions are needed:
$ du -s --inodes . # (with GNU du)

Have a nice day,
Berny

Bernhard Voelker <berny>
Project AdministratorIn charge of this item.
Mon 26 Nov 2018 08:05:22 AM UTC, comment #3:

I think you missed the "do it well" part. Using --print to feed the pipe you create a terrible overhead, compared to an internal i++. find has to obtain the file names and call write to copy each one to stdout. Not to mention that the shell has to establish the pipe, search "wc", and run it to read each line, call i++ and forget each line.

I am not asking anybody to give up his favorite pipe constructs, but IMHO an option "--count" would be an improvement to find.

Harald Dunkel <harri>
Sun 25 Nov 2018 08:36:04 PM UTC, comment #2:

This would be counter to the Unix philosophy of small programs that do one thing well that can be combined together to perform new useful things.

This is just one example of something that is unpredictably needed but can be created as needed using the low level tools. Which is why it should not be done. What else would need to be added too? Should spell checking be added to find in case someone wants to spell check files in a directory tree? There is really no end to the creeping featurism problem once one starts down that path.

Bob Proulx <rwp>
Project Member
Sun 25 Nov 2018 05:35:06 PM UTC, comment #1:

FWIW I think this is a terrible idea. Combining find and wc to count matches
(a) works very well
and
(b) is accessible. People who know the basic find syntax and know the existence of wc will do it exactly this way, instead of looking into find(1) to check whether this implementation features a non standard, not portable way to count matches.

GNU find already has too many options.

Andreas Metzler <ametzler>
Sun 25 Nov 2018 04:14:11 PM UTC, original submission:

To get rid of lines like "find /somewhere --someflags --print | wc -l" it would be very helpful if find could simply count and print the result on its own. Command line would be

% find /somewhere --someflags --count
42

Harald Dunkel <harri>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by rwp (Posted a comment)
  • -email is unavailable- added by harri (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-09 berny StatusNone => Wont Fix
        Assigned toNone => berny
        Open/ClosedOpen => Closed
    2018-11-26 berny Severity3 - Normal => 1 - Wish

    Back to the top


    Powered by Savane 3.4