bugfindutils - Bugs: bug #13650, find -exec rm -i {} \; broken...

 
 

bug #13650: find -exec rm -i {} \; broken since 4.2.12

Submitter:  Andreas Metzler <ametzler>
Submitted:  Wed 06 Jul 2005 08:40:13 AM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  Open/Closed:  Closed
Release:  4.2.12 Fixed Release:  4.2.24
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 12 Jul 2005 08:36:37 PM UTC, comment #9: 

Changing it certainly is not out of the question, but I am trying to bear in mind the bug report at bug #3992.

James Youngman <jay>
Group administrator
Tue 12 Jul 2005 04:31:45 PM UTC, comment #8: 

Jay wrote:

> I understand but that is not how -ok works


Yes I realized that. :-) Is it going to change or is it to difficult? (I am sure somebody could come up with a sensible usage of -ok <interactive program>)

If changing is out of question (for whatever reason, be it difficult or you thinking "stupid idea") could you apply attached patch to the documentation?

           thanks, cu andreas

Anonymous
Tue 12 Jul 2005 03:47:04 PM UTC, comment #7: 

i understand, but that's not how -ok works.  OK is like -exec, it doesn;t just ask it actually runs the command.   Hence the nearest thing to what you're talking about that would actually work is

find ... -ok true {} \;  -a -exec rm -i {} \;

As you point out, this would ask twice.  Given the current code, the "true" command would not be able to read from stdin, but doesn;t try, while the "rm -i" command would be able to read from stdin.   So, what you wanted already works.

If you were doing this for real though, this is probably better, but only asks once:

find ... -ok  rm {} \;

This is neater, but asks only once, since "rm" would not be able to read from stdin.

James Youngman <jay>
Group administrator
Tue 12 Jul 2005 03:16:52 PM UTC, comment #6: 

Hello,
sorry my incoherent mail.

I was actually thinking about (the useless example)

find ... -ok rm -i {} \;

which I'd expect to ask twice: first find asks, and if that succeeded would pass on stdin/out to rm which ask again.
        cu andreas

Anonymous
Sun 10 Jul 2005 01:29:12 AM UTC, comment #5: 

One potential problem here is that if a prepared file is being fed to find on stdin, the command executed by -ok can steal its input.     That's why the current findutils code runs programs for "-ok" with stdin redicrected from /dev/nul, but still runs programs for "-exec" with stdin unchanged.

In the example you give I assume you're changing the -o in the example to -a:

find a b c -mtime 2 -ok prog1 {} \; -a -exec rm -i {} \;

That is, if "prog1" returns 0, rm -i will be called on the file currently being considered.  That will work with the (now) current development code. If that's what you're asking for, no problem, that's what we have right now.  Or are you asking for something else?


James Youngman <jay>
Group administrator
Fri 08 Jul 2005 09:41:53 AM UTC, comment #4: 

James Youngman wrote

> find a b c -mtime 2 -ok prog1 {} \; -o -exec prog2 {} \;
>
> With the (now) current code, prog2 will be able to read from
> stdin but prog1 will not. Is this really sensible?


Well, it sure would be nicer if -ok and "-exec rm -i {} \;" worked together, i.e. first find asks and if that is succesful rm can access stdin.

Andreas Metzler <ametzler>
Wed 06 Jul 2005 10:28:26 PM UTC, comment #3: 

Consider this example:

find  a b c -mtime 2 -ok prog1 {} \; -o -exec prog2 {} \;

With the (now) current code, prog2 will be able to read from stdin byt prog1 wil not.  Is this really sensible?

James Youngman <jay>
Group administrator
Wed 06 Jul 2005 10:25:26 PM UTC, comment #2: 

The initial patch also allows programs run via -ok to sleal the input stat "ok" wanted to read, so this modicied patch behaves differently for -ok and -okdir.

James Youngman <jay>
Group administrator
Wed 06 Jul 2005 10:02:00 PM UTC, comment #1: 

Alternative test case:

touch a b
find a b -maxdepth 0 -exec rm -i {} \;
echo
ls -l a b
rm a b

The problem was introduced when find was refactored to use the same command-builder as xargs.  The xargs command needs this behaviour, but find does not.

I have applied the attached patch, which I think should solve the problem.

James Youngman <jay>
Group administrator
Wed 06 Jul 2005 08:40:13 AM UTC, original submission:  

Starting with version 4.2.12 (i.e. 4.2.11 works) invoking interactive commands from -exec is broken, it looks like stdin is connected to /dev/null.

Simple testcase:
touch a b
find -maxdepth 1 \( -name a -or -name b \) -exec rm -i {} \;

This was found by Matias Rollan in http://bugs.debian.org/317019

thanks, cu andreas

Andreas Metzler <ametzler>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #3213:  patchdocs.diff added by None (2KiB - text/x-patch - document stdin redirection from /dev/null for find -ok(dir))
file #3167:  savannah-bug-13650-proposal2.patch added by jay (5KiB - text/x-patch - Second proposed patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ametzler
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2005-07-29 jay StatusNeed Info Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.2.24
    2005-07-12 jay Carbon-Copy- Added egmont
    2005-07-12 None Attached File- Added patchdocs.diff, #2694
    2005-07-06 jay StatusNone Need Info
    2005-07-06 jay Attached File#2661 Removed
    2005-07-06 jay Attached File- Added savannah-bug-13650-proposal2.patch, #2662
    2005-07-06 jay Item GroupNone Wrong result
        Assigned toNone jay
        ReleaseNone 4.2.12
        Attached File- Added savannah-bug-13650-proposal.patch, #2661
    2005-07-06 ametzler Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code