Talk:find (Unix)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Linux only example[edit]

I've taken this edited text from the article for comments, because it only works for Linux. I've tested it on AIX, Solaris, and HP-UX. This is what I got, instead of the whole structure. 

0       ./outputDirectory/{}
0       ./outputDirectory

Recreate a directory structure (without files)[edit]

This command finds the directories (-type d) within the current directory (.) and makes the new directories in the '~/outputDirectory'. The tilde (~) represents your home directory (e.g. /home/joeBloggs). 

find . -type d -exec mkdir -p ~/outputDirectory/{} \;

My question is, should this be redone to work in all Unix flavors, or just left out? Gbeeker 12:31, 17 February 2006 (UTC)[reply]

This appears to be related to the shell, rather than the OS. On bash, it works. On tcsh, it does not. This one works for tcsh:
find . -type d -exec mkdir -p ~/outputDirectory/'{}' \;
The man page actually warns that both {} and ; may need escaping from the shell. Maybe we can just leave this example out, as the article already contains examples about executing a command for all files in a directory. - Liberatore(T) 15:10, 17 February 2006 (UTC)[reply]
I thought that the ~user home directory was worth mentioning, so I worked it into another example. I also mentioned a bit about quoting, in case a space is a search term. The escaping ; and {} from the shell I did leave out. The Korn shell (ksh) allows escaping with a \ or single quotes. Unixguy 15:21, 20 March 2006 (UTC)[reply]

The reason we get this result on some systems is that the interpretation of {} when it's part of a longer argument differs:

If a utility_name or argument string contains the two characters "{}", but not just the two characters "{}", it is implementation-defined whether find replaces those two characters or uses the string without change.

This is a portable way of achieving the same thing: 

find . -type d -exec sh -c 'cd outputDirectory && mkdir -p "$@"' fnord {} \+

Unfortunately the method above fails to preserve directory ownership and permissions, but this method avoids that problem: 

 find . -type d -print | cpio -pmd ~/tmp/x

JamesYoungman (talk) 17:47, 1 June 2014 (UTC)[reply]

Alternatives to find[edit]

I am interested to hear of any alternatives to find. What programs are there that solves the same problems on Unix? I am not thinking of indexing programs such as Beagle. I find finds syntax archaic. For example, I don't think find works with xattrs. 213.67.93.121 21:58, 26 April 2007 (UTC)[reply]

find's syntax is not "archaic". It is idiosyncratic, powerful, and difficult to master. Just because you haven't crested the extremely harsh learning curve yet doesn't mean it's obsolete. —Preceding unsigned comment added by 204.27.178.252 (talk) 18:22, 26 March 2009 (UTC)[reply]
With the -exec parameter you can execute an arbitrary command, so I guess it's possible to make find work with Extended file attributes, provided you have a program (as opposite to just system calls or library functions) to check them. I am not aware of any direct alternative to find, but I guess there may be some (especially some providing a GUI frontend). Tizio 12:17, 28 April 2007 (UTC)[reply]
Ffind might be graphical alternative to find on Windows. Wkpen (talk) 18:28, 19 October 2016 (UTC)[reply]

I removed the link to searchmonkey. Why reference it but Nautilus and Konqueror's built-in search tools, Beagle, Tracker, Strigi, etc. PuerExMachina 05:33, 16 November 2007 (UTC)[reply]

Tried to add[edit]

NOTE: You mistook + for -. The first line should be -4, the second +20. IEEE, IEEE (talk) 10:51, 7 April 2008 (UTC)[reply]

I tried to add

Search current directory for files modified less than 4 days ago and print long[edit]

find . -mtime +4 -exec ls -l '{}' ';'

Search for files modified more than 20 days ago and list long, oldest first[edit]

find . -mtime -20 -exec ls -lrt '{}' ';' but soon found to my dismay that my quest to deduce how you would do either of these in Linux still eludes me. They yield what seem to be files in the directory with random dates. --previous unsigned comments added by User:68.123.188.129.

Both searches includes the current directory (.) Therefore, "ls -l {} ;" actually includes a listing of the current directory. The second command do not work also because when "ls -ltr" is run, its argument is already a single file, so this is equivalent to "ls -l". - Liberatore(T) 11:50, 7 March 2006 (UTC)[reply]
You would have 2 options to get the files modified more than 20 days ago. First note that the find command scans the directory structure, and the ls command is run once for each file found, so the sort options for ls (-t and -r) have no effect, as Liberatore noted above.
Add -type f finds only types of 'file', and not directories.
find . -type f -mtime -20 -exec ls -l '{}' ';'
Or use the -d option to ls which will show the directory inode details, not the contents of the directory itself.
find . -mtime -20 -exec ls -ld '{}' ';'
So, it is actually difficult to get these files sorted by date, but there are ways to do it. You may want to search the newsgroup comp.unix.shell, and see the FAQ for examples. --Unixguy 12:00, 24 April 2006 (UTC)[reply]

Doesn't 

 ls -ltrd $(find . -mtime -20)

do what you want? JamesYoungman (talk) 17:57, 1 June 2014 (UTC)[reply]

Formated printing with Find[edit]

is it possible to format the output of the -print switch for the find command? Abountu 17:27, 18 September 2006 (UTC)[reply]

GNU find has -printf. JamesYoungman (talk) 17:48, 1 June 2014 (UTC)[reply]

this is a really useful page but the name is too generic, it should be something like "Find (Unix)". Agree? —Preceding unsigned comment added by Searchtools (talk • contribs) 00:38, 24 January 2008 (UTC)[reply]

3.4 Finding exact matches for times?[edit]

  • Sigh,* sometimes Wikipedia articles are context-free. Is there a rationale for `find` having the ability to match 24-hour periods that start arbitrarily from the time it is run but not exact dates, such as "find all files modified between 9AM and 5PM on January 1 in my locale?" What's the shortest incantation to accomplish that without resort to perl? —Preceding unsigned comment added by 155.212.34.122 (talk) 23:42, 29 January 2009 (UTC)[reply]


If you are using BSD find or (recent versions of) GNU find, you can use the test -newermt. JamesYoungman (talk) 17:58, 1 June 2014 (UTC)[reply]

Removal of "Windows commands" template[edit]

I removed the "Windows commands" template from the end of this article. While Windows does have a "find" command, it is much different than the UNIX command described in this article. The Windows "find" command (actually, it was part of MS-DOS before Windows existed) is actually more like the UNIX grep command. And the DOS/Windows find (command) as its own article, anyway. --Lance E Sloan (talk) 17:44, 24 February 2009 (UTC)[reply]

Error in Search_for_a_string section[edit]

The Search_for_a_string section says "The ... single quotes (' ') surrounding the braces ... needed to allow spaces and other special characters."

This is not technically true. The single quotes are not needed. The following is a Linux demonstration without single quotes surrounding the braces. 

bash-3.2# mkdir 'directory with spaces'
bash-3.2# echo -e 'Hello world\nthis is a test' >'directory with spaces/file with spaces'
bash-3.2# find 'directory with spaces' -type f -exec grep -l test {} \;
directory with spaces/file with spaces

-Ben Collver —Preceding unsigned comment added by 75.145.67.114 (talk) 16:21, 22 September 2010 (UTC)[reply]

Solaris version of find[edit]

The Solaris version of find does not support the -path or -ipath options, and probably has a number of other differences. Considering how widely used Solaris is, it should probably be noted in the article.

Jeff The Riffer (talk) 15:53, 15 November 2010 (UTC)[reply]

POSIX protection from infinite output[edit]

is this impossable becuse of the Halting problem.Confront (talk) 07:08, 19 January 2011 (UTC)[reply]


No, not at all. The Halting Problem applies only to turing-complete languages (or at least, similarly powerful languages). The language that Find accepts isn't nearly that powerful. In particular the language lacks loops and recursion. JamesYoungman (talk) 17:53, 1 June 2014 (UTC)[reply]

Path optional in some versions of find[edit]

I've changed the syntax to not use [path]; it's NOT optional in most versions of find (except GNU find), and often causes problems when unportable shell scripts are written.

Also, it makes no sense to have [path] and then say that path is mandatory later in the same paragraph.

A general note on this level of detail in this article[edit]

I just wish this great amount of detail as at display in this article would be applied by he exact detail-oriented people in articles on social themes as well. Or in oher words : This article here is one of those reasons why people say that Wikipedia has a HUGE bias towards tech-oriented themes, and that Wikipedia is rather driven by technology nerds than by normal people.

There are SO many articles out there in dire need of a similar level of detail as one can see in this article here - however, the "Technology Nation" just doesn't bother. The authors who put so much energy into creating an article of this incredibly high level of detail just don't bother about what's going on in the rest of the world.

No "casual" Wikipedia user will ever see these kinds of articles like this one here where the amount of detail research is astounding - and therefore, the casual" Wikipedia user will never ever notice the difference in levels of detail in "non-geekish" Wikipedia articles. There are *so* many Wikipedia articles that remain a "stub", because no-one cares to implement the same level of detail there as one can perceive here.

Of course, if it's a non-technical theme, it is of no importance, the cynic in me says.

It's time to rename Wikipedia into "Geekipedia", the cynic in me claims. Alrik Fassbauer (talk) 13:37, 2 March 2012 (UTC)[reply]

This complaint is kind of silly. The author(s) of this piece took the time to add this level of detail. It's not their fault that authors of other articles don't take the same time with theirs. Wikipedia is your online encycopedia. If you want it improved somewhere, go do it. Tim Bird (talk) 23:16, 13 August 2014 (UTC)[reply]

Requested move 15 September 2017[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Pages moved. Kindly see Talk:Find (Windows)#Requested move 15 September 2017 for a detailed explanation. —usernamekiran(talk) 14:49, 23 September 2017 (UTC)[reply]


– There is obviously no primary topic for a common English word, I doubt most people searching this would be looking for a Unix command, even though it [https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=Find - CHAMPION (talk) (contributions) (logs) 00:25, 15 September 2017 (UTC)[reply]

@Champion: See also related RM at Talk:Find (command) -> Find (Windows). In ictu oculi (talk) 11:29, 15 September 2017 (UTC)[reply]
  • Support Even if there was not the Windows equivalent, I somehow doubt that a UNIX system command is the WP:PRIMARYTOPIC for "find", and considering that as well, the decision is clearcut. No such user (talk) 14:08, 15 September 2017 (UTC)[reply]
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Find_(Unix)&oldid=1202005016"