39

Is there an alternative find program with a more conventional CLI interface? find works and expects parameters in a painfully different way from most other utils.

Clarification: I'm looking for a program that has mostly the same functionality as find with a commandline interface that works and feels like POSIX (or at least GNU) commandline recommendations.

Improve this question
17
  • 10
    GNU find does not respect POSIX (or even GNU) guidelines for command line. For example, ordering of parameters, multi-character options with a single dash etc. are different than in conforming programs. Commented May 20, 2011 at 11:11
  • 3
    I know, and I can always do what I intend, one way or another. I just recently got to know ack and was wondering if there is a better find as well. Commented May 20, 2011 at 11:40
  • 2
    No. You see, I don't want a small programming language, but a simpler, more intuitive and more consistent find (even if that means the loss of some advanced functionality). When I face a task that justifies writing a program, I do. Commented May 20, 2011 at 14:28
  • 3
    @tamas I edited an hour ago and told you there's no alternative except locate. And maybe ls -R come to think of it. Other alternatives are GUI programs that emulate find. Otherwise you have to specify what you want your find alternative to do. Walk dir trees? Filter file names? Tell you which files is newer then? Commented May 20, 2011 at 17:24
  • 6
    Great question, poor answers, and even worse comments. I like how they're trying to convince you that no, really, you want to use find, even though you hate it. Commented Oct 28, 2016 at 12:19

6 Answers 6

Reset to default
13

I would take a look at locate. It will look through its database of files and quickly print out path names that match what you give.

kevin@box:~$ locate odg /home/kevin/Documents/final.odg /usr/share/doc/packages/sysconfig/netconfig.odg /usr/share/gimp/2.0/help/en/gimp-tool-dodge-burn.html .... kevin@box:~$ locate .odg /home/kevin/Documents/final.odg /usr/share/doc/packages/sysconfig/netconfig.odg kevin@box:~$

As you can see, it is a sub-text match: if you give it odg, then it will match dodge. But if you give it .odg, then it won't.

There is one downside, though: it needs a database. This database needs to be updated when things change. My Fedora 13 install has this put into a daily crontab, though.

Improve this answer
2
  • I love locate Commented May 21, 2011 at 10:00
  • 1
    Moreover, locate also accepts patterns (I learned this just recently). Commented May 21, 2011 at 17:55
11

This is a common misconception.

Find follows the options syntax. You're just confusing expression primaries with options:

 find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression] [cmd][--> options <--] [--> arg0..argN <--]

The alternative is locate. But find implements its own expression syntax because it provides a richer set of filter and action options. There's no alternative that can do the same, simply because it would be redundant.

Improve this answer
5
  • What is the difference between expression (only one allowed?), cmd (dito?), options and args? Commented May 20, 2011 at 15:35
  • @user unknown -- the find command implements it's own expression syntax. The expression, when given, is the last argument on the command line. When absent, expression resolves to -print. Commented May 20, 2011 at 16:03
  • Ah - now I see, [cmd] isn't following [expression], but it's a description of the line before. Commented May 21, 2011 at 3:04
  • 7
    OP asserts that find "expects parameters in a painfully different way from most other utils". You state that OP is "confusing expression primaries with options". Do most other utils even have a concept of "expression primaries"? If not, doesn't that demonstrate OP's point? And that's really not the strangest part of using find. What other CLI involves {} (which of course must be escaped somehow)? Commented Aug 24, 2017 at 16:39
  • I hope someone makes a modern tool, like the way mc makes ls seem outdated, and ncdu makes du seem outdated, and zsh / fish makes bash seem outdated. I want an nclocate . which makes locate operate on a path with autocomplete in realtime, like google does for websites, or Ctrl-F does in nautilus GUI Commented Sep 29, 2017 at 17:50
10

It depends on the precise functionality of find that you are relying on. If it is (principally) the finding functionality, some shells support recursive globs. E.g., with zsh:

% find . -name \*c ./a/b/foo.c ./a/bar.c ./baz.c inoshiro% ls *.c baz.c % ls **/*.c a/bar.c a/b/foo.c baz.c

Zsh has a lot more find-like possibilities through glob qualifiers (look near the end of man zshexpn). For example:

ls -l **/*(.)  ≈  find -type f -ls
ls *(m-2u:$USER:)  ≈  find -mtime -2 -user $USER

Bash 4 also has **/ (you need to enable it with shopt -s globstar), but nothing like glob qualifiers.

Improve this answer
6

What are you trying to find? If you're typically searching for source code files, take a look at ack. It's basically a source code search tool, but ack's -f switch will find files that match a given filetype.

So if you want to find all the Perl files in a directory, for example, just:

ack -f --perl

If you don't like the filetypes that ack recognizes, you can add your own in your ~/.ackrc.

ack is not a general-purpose file finder like find, but if you're working with source code, it can be very handy.

Improve this answer
1
  • 1
    This is not what user asked but people might find very useful for find in source code (like grep) The Silver Searcher, silversearcher-ag package on main distros. Commented Jul 12, 2017 at 22:20
0

One of the great things every programmer should learn is: If you can't find a tool, build your own!

#!/usr/bin/bash find -name $<

I might write a better one, with -t to filter types, etc.

Edit: The above is a Bash script. It takes the command line argument and passes it to find as the -name option's value. Just a simple example. Since I put up this answer, I found this python script:

https://github.com/sjl/friendly-find/

The interface looks nice, but I haven't tested its performance. Might be worth checking out.

Improve this answer
3
  • 1
    True for building own tool statement. But at least explain how your little script is supposed to work. Commented Dec 16, 2012 at 9:27
  • 1
    $< is not doing anything useful in my Bash. What do you expect it to do? Do you mean "$@" actually? Or "$1" (which is basically what this means in a Makefile)? Commented May 9, 2017 at 7:21
  • 2
    @tripleee - $< is the csh equivalent of read - I'm guessing he meant that. Commented May 9, 2017 at 13:40
0

Most standard way to find things in unix's. 

du -a <directory>|grep <pattern>| awk '{print $2}'
Improve this answer
3
  • 1
    grep | awk is an antipattern. See useless use of grep. If you want to parametrize the pattern, maybe du -a | awk -v "pat=<pattern>" '$0 ~ pat { print $2 }' Commented May 9, 2017 at 7:24
  • 1
    @tripleee That's very helpful info about awk, but one of the great advantages of the UNIX philosophy is that one doesn't need to understand all the features of the more complex tools (such as awk and find) in order to construct pipelines that can perform the desired task. grep | awk may not be optimal (or, on a performant multithreaded system with a highly optimized grep, maybe it would be!), but it's simple. Commented Aug 24, 2017 at 16:43
  • it works. It cannot be downvoted if it works as a solution, Can be improved though. Commented Aug 4, 2022 at 5:38

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.