Almut Behrens wrote:
I'm running testing, and dpkg says I'm using bash 3.0-15 and findutils
4.2.22-1.
It seems to be a bug (or feature?) of find.
(I can even reproduce the behaviour when moving the debian-testing find
binary to a somewhat older SuSE box -- where the command in question
Andrew Schulman wrote:
On Tue, Jul 05, 2005 at 05:51:07AM -0400, Andrew Schulman wrote:
find ... -print0 | xargs -0r rm -i
This won't work because rm -i reads for confirmation from stdin and rm
has no stdin when it's run via xargs.
Hm, you're right. Well one alternative that will
Almut Behrens wrote:
(It's called from within launch(), which is handling the option -exec)
This function is simply not present in the old sources (4.1.20).
Well, I guess it's worth filing a bug report, to let the original
authors figure out what it was that made them add this code -- and
I have a script called texclean as follows:
#!/bin/sh
if [ -z $1 ]; then
DEPTH=1;
else
DEPTH=$1;
fi;
for PATTERN in '*~' '*.log' '*.aux' '*.bbl' '*.blg' '*.toc' \
'*.lof' '*.lot' '#*#';
do
find . -maxdepth $DEPTH -name $PATTERN -exec rm -i '{}' ';';
done
Recently it
On Tuesday, 05.07.2005 at 10:03 +0100, Adam Funk wrote:
I have a script called texclean as follows:
#!/bin/sh
if [ -z $1 ]; then
DEPTH=1;
else
DEPTH=$1;
fi;
for PATTERN in '*~' '*.log' '*.aux' '*.bbl' '*.blg' '*.toc' \
'*.lof' '*.lot' '#*#';
do
find .
I have a script called texclean as follows:
#!/bin/sh
if [ -z $1 ]; then
DEPTH=1;
else
DEPTH=$1;
fi;
for PATTERN in '*~' '*.log' '*.aux' '*.bbl' '*.blg' '*.toc' \
'*.lof' '*.lot' '#*#';
do
find . -maxdepth $DEPTH -name $PATTERN -exec rm -i '{}' ';';
done
Dave Ewart wrote:
Recently it stopped working because rm -i in find... no longer
appears
connected to the console for input. Typing find -name '*~' -exec rm -i
'{}' ';' directly prints a list of rm-questions, doesn't get an answer,
and so does nothing.
Why did this behaviour change, and
Andrew Schulman wrote:
Why did this behaviour change, and how can I fix my script?
An alternative is
find ... -print0 | xargs -0r rm -i
I get the same problem with that!
$ find . -name '*~' -print0 |xargs -0r rm -i
rm: remove regular file
On Tue, 2005-07-05 at 11:36 +0100, Adam Funk wrote:
Andrew Schulman wrote:
Why did this behaviour change, and how can I fix my script?
An alternative is
find ... -print0 | xargs -0r rm -i
I get the same problem with that!
$ find . -name '*~' -print0 |xargs -0r rm -i
rm:
michael wrote:
Well on 'sarge', under bash, the
find . -name 'whatever' -exec rm -i {} ;
works as expected for me, but the above example exhibits the same
performance as you note (I'm no 'xargs' expert and can's see what the
'-0r' option is meant to do)
If I were you I'd check that the
On Tue, Jul 05, 2005 at 05:51:07AM -0400, Andrew Schulman wrote:
find ... -print0 | xargs -0r rm -i
This won't work because rm -i reads for confirmation from stdin and rm
has no stdin when it's run via xargs.
--
Dave Carrigan
Seattle, WA, USA
[EMAIL PROTECTED] | http://www.rudedog.org/ |
On Tue, Jul 05, 2005 at 12:41:48PM +0100, Adam Funk wrote:
michael wrote:
Well on 'sarge', under bash, the
find . -name 'whatever' -exec rm -i {} ;
works as expected for me, but the above example exhibits the same
performance as you note (I'm no 'xargs' expert and can's see what the
On Tue, Jul 05, 2005 at 05:51:07AM -0400, Andrew Schulman wrote:
find ... -print0 | xargs -0r rm -i
This won't work because rm -i reads for confirmation from stdin and rm
has no stdin when it's run via xargs.
Hm, you're right. Well one alternative that will definitely work is
find ...
P.S. The reason that find ... -print0 | xargs -0r rm -i exhibits the
same behaviour is a different one: Here, find's stdin filehandle would
somehow have to be passed through to rm (via xargs, which in turn has
its stdin attached to find's stdout), in order for rm to be able to
read from the
14 matches
Mail list logo
