[»]
Re: Advantages over find?
by Andy Kirkpatrick - Mar 22nd 2004 16:34:31
I don't think the argument for use of "ff" is so clear cut. I often just
use:
for i in *.tgz; do tar xvzf "$i"; done
Or, depending on the argument processing, use find with xargs:
find '*.txt' | xargs grep -i caveat
Xargs BTW can limit the number of simultaneous subprocesses with -P, and
the number of arguments passed to each instance with -n, both of which
default to one.
Of course looping in the shell isn't recursive and limited by the argument
buffer (so is calling ff *.tgz though). While not so limited, the
"find|xargs" solution spawns subprocesses so "ff" does seem to have a niche
- but perhaps not so large as made out.
[reply]
[top]
[»]
Re: Advantages over find?
by Suraj N. Kurapati - Mar 22nd 2004 18:53:58
> Of course looping in the shell isn't
> recursive and limited by the argument
> buffer (so is calling ff *.tgz though).
Good point.
A command line option, which allows a list of targets (non-directories or
directories) to be read from a file, will be added in the next release.
This will enable the user to bypass the size limit of the argument
buffer.
Thanks.
[reply]
[top]
[»]
Re: Advantages over find?
by kili - Jun 19th 2004 03:33:42
Why such -- rather complicated -- bash magic?
What's so bad on just teaching people clever use of
standard tools as sh(1), find(1), xargs(1), sed(1) etc?
For example, renaming .tgz to .tar.gz can be done
with a simple command line:
find $some_path -type f -name \*.tgz | sed
's/\(.*\)\.tgz/mv & \1.tar.gz/' | sh
When unsure, run that command without the trailing |
sh to see what would happen. Or run it with | sh -x to
see *what* actually happens.
Note that this example is a *oneliner*, so with a little
bit more magic, you could easily make it robust
against weird filenames (containing whitespace,
quotes and thelike). However, neither ff nor a
combination of find(1), sed(1) and sh(1) as above
can handle filenames with newlines. You've to use
find ... -print0 | xargs -0 for this, which unfortunately is
a GNU extension.
Ciao,
Kili
[reply]
[top]
[»]
Re: Advantages over find?
by Suraj N. Kurapati - Jun 19th 2004 15:04:23
> Why such -- rather complicated -- bash
> magic?
Making use of the shell's builtin constructs yeilds better performance
than invoking external programs.
> What's so bad on just teaching people
> clever use of
> standard tools as sh(1), find(1),
> xargs(1), sed(1) etc?
I agree. Please note that this tool is not meant to replace any existing
tools; it simply aims to facilitate alternative approaches to performing
filesystem manipulation tasks.
> For example, renaming .tgz to .tar.gz
> can be done
> with a simple command line:
>
> find $some_path -type f -name \*.tgz |
> sed
> 's/\(.*\)\.tgz/mv & \1.tar.gz/' | sh
That's a good solution and notice that you also have utilized an
intermediate shell 'sh' in solving the example problem. This observation is
detailed in my response to the question at the root of this thread.
> When unsure, run that command without
> the trailing |
> sh to see what would happen. Or run it
> with | sh -x to
> see *what* actually happens.
>
> Note that this example is a *oneliner*,
> so with a little
> bit more magic, you could easily make it
> robust
> against weird filenames (containing
> whitespace,
> quotes and thelike). However, neither ff
> nor a
> combination of find(1), sed(1) and sh(1)
> as above
> can handle filenames with newlines.
> You've to use
> find ... -print0 | xargs -0 for this,
> which unfortunately is
> a GNU extension.
This is a limitation of the GNU Bash shell as there is currently no way to
express the ASCII NUL character '\0' in its scripting language. Also, such
arbitrary filenames with newlines in them are a rather special case in most
POSIX systems. Thus, in accordance with the common Engineering design rule:
"make the common case fast", the handling of newlines in filenames is best
left to the 'xargs' tool.
> Ciao,
>
> Kili
>
Thanks.
[reply]
[top]
[»]
Re: Advantages over find?
by Suraj N. Kurapati - Jul 20th 2004 18:18:10
> This is a limitation of the GNU Bash
> shell as there is currently no way to
> express the ASCII NUL character '\0' in
> its scripting language. Also, such
> arbitrary filenames with newlines in
> them are a rather special case in most
> POSIX systems. Thus, in accordance with
> the common Engineering design rule:
> "make the common case fast", the
> handling of newlines in filenames is
> best left to the 'xargs' tool.
>
The above statement is false.
This tool can handle file names that contain new-line characters,
as was proven in a comp.unix.shell newsgroup post (Message-ID:
<2m5ifuFjctd8U1@uni-berlin.de>). Furthermore, we can generate
the NUL character in BASH scripts: echo $'NUL is \000'.
[reply]
[top]
[»]
Re: Advantages over find?
by Stephan Loh - Jul 10th 2004 14:52:31
> For example, renaming .tgz to .tar.gz
> can be done with a simple command line:
>
> find $some_path -type f -name \*.tgz | sed 's/\(.*\)\.tgz/mv &
\1.tar.gz/' | sh
You could also use this command:
tgz -> tar.gz
for i in *tgz; do mv $i `echo $i | sed s/tgz/tar\.gz/`; done
tar.gz -> tgz
for i in *tar.gz; do mv $i `echo $i | sed s/tar\.gz/tgz/`; done
or, if you want to use more complicated mechanisms to find files and
therefore want to use the `find' command, use this:
for i in `find . -type f [--further-options] -name "*tgz"`; do mv $i `echo
$i | sed s/tgz/tar\.gz/`; done
[reply]
[top]
[»]
Re: Advantages over find?
by Suraj N. Kurapati - Jul 17th 2004 13:01:20
My previous response to this question contains errors. Below is an
updated and correct response from the FAQ (located at: http://ff-bash.sourceforge.net/docs/faq.html).
There is one advantage, which can be observed under the following
conditions. If find -exec is used to invoke an intermediate shell: $
find . -exec sh -c '...' \;, then it will expend more system resources
than For each File. This is because, for each file it handles, find -exec
will fork a child process (the intermediate shell) and thereby cause the
operating system to perform a context switch. In contrast, For each File
will invoke a GNU BASH function that is already loaded into memory and thus
does not cause a context switch. This behavior reduces the number of
process forks and thereby expends less system resources as compared to find
-exec under said conditions.
[reply]
[top]
