[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I am not sure if this is a bug. But the change can be very important
From: |
James Youngman |
Subject: |
Re: I am not sure if this is a bug. But the change can be very important for people using bigger media and search files on it |
Date: |
Fri, 29 Mar 2013 21:24:31 +0000 |
On Fri, Mar 23, 2012 at 4:14 AM, Enjay Linux <address@hidden> wrote:
> I am using 1-3 TB disks
>
> Searching file is always very crucial for me and more importantly making it
> more faster is always the challenge for me
> with find it takes lot of time to find any file on such a big media
>
> So I prefer to use locate to find files. No problems but
> when I want to find files based on their size or modification/creation date
> and time I prefer using combination of find and locate as shown below
> find $(locate filename*) anyfindoption
> where any filename* is any file that I am trying to find as well as
> anyfindoption is the option that I use to find files by size / date / time
> It all works perfectly until there are normal file names
>
> but as and when there is a file name with spaces
> find reads the output of locate in divided form
> Eg. if file name is (this is my file.txt) without brackets
> find will read it all as different files like this, is, my, file.txt
> and so it will generate error saying
>
> find: `/home/enjay/this': No such file or directory
> find: `is': No such file or directory
> find: `my': No such file or directory
> find: `folder': No such file or directory
This happens because of the way the shell handles the effect of
$(...). For the full details you can read the documentation for
whichever shell you are using (if it's Bash, you can take a look at
the sections "SIMPLE COMMAND EXPANSION" and "Word Splitting" in the
manpage).
But, this should do what you want (of course you should vary the
details of the tests):
$ locate --null bath | xargs --null sh -c 'find "$@" -size +200
-print' use_this_as_argv0
However, if you have pathnames containing spaces (and especially
newlines) you might consider using -print0 instead of -print. Though
in that case you will need to consume the output with something that
will accept NUL-separated items (such as GNU sort with the -z option).
James.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: I am not sure if this is a bug. But the change can be very important for people using bigger media and search files on it,
James Youngman <=