Re: -ok not totally OK

[jidanni]

OK, but considering
> A workaround to revive stdin on -ok is: -ok true \; -exec
Will you
A. Clamp down stdin on -exec too, for my own good; or
B. Mention the workaround on the man page; or
C. Stop clamping stdin on -ok, as people will just workaround it
anyway, and just say you will read up to a RET or whatever the shell
reads up to.

        The -ok primary shall be equivalent to -exec, except that the use of a 
plus sign ...

So if you are going to "mess up" the stdin of one, you should mess up
that of the other (there might be lots: -exec ... -exec ... -ok ...
-exec ..., must we play net-nanny? Best to not mess. Does the shell
choose to tinker with the stdin of the programs it calls? So why
should find(1)? Just state that you will read up to a RET. Anyway, I
want to use -ok and -exec to play certian .mp3s so need my stdin not
messed with.

>> Also it seems an -ok + and -okdir + could be implemented just as there
>> now is -exec + and -execdir +.

EB> POSIX explicitly allows the omission of -ok +.  Besides, what semantics
EB> would you give it?  Is it an all-or-none action on the directory?  If you
EB> still end up asking once per file, then what good did it do?

Perhaps: we will save the chosen ones all up and run them at the very
end. Or: ... and run them including this one when you hit a instead of
y... oops, can only hit y according to spec. OK, leaving it up to your
creativity. Just unhand my stdin.