On Wed, Jan 14, 2009 at 8:56 AM, Matthew Woehlke <----> wrote: >> -i -n would ask, and then say, can't overwrite or similar. > > I don't think that makes sense... why are you asking if you won't do it > anyway?
because if I put a -i in my alias, then I want it to ask every time! Sometimes I want to follow along with what's happening, and I can't do that if it doesn't prompt for each file. Now -n -i , shouldn't ask as one answer to your question but -i -n should ask because I put -i there to follow thru with what the cp/program is doing. The message should be unobtrusive and I'm guessing that simplification is part of why everything is limited just the last occurrence of mutually exclusive options. However, stderror and stdout go to stdout for me.. so is there another stdmessage or something? I could do 3>stdout and get the messages that I crave. > >> I believe that might not be the posix way though... Image magick >> order matters... actually in cp order matters... So order could >> matter here too. > > The order of -f and -i already matters, as I understand, so I don't see the > problem extending that to -n (especially as -f, -n and -i are all closely > related). Yes, the order matters the way it is being expected... -i -n would not ask at all! it would loose the interactivity that is why I would put the thing in my alias! If I didn't want the -i I would have called the program by it's full path /bin/cp If I put cp= cp -n Basically -f and -n are exclusive as far as I can tell... but the posix rules don't make sense to me.. having -n in my alias cp=cp -n then doing a cp -f which expands to cp -n -f defeats the point of me having cp -n in my alias. If I didn't want cp to always be -n then I could have made another alias for it. Alas, to get the best behaviour for everyone, current behavior would have to be maintained, and have some sort of immutable notation, that would error out if cp -exclusive(-n) -f occured. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
