Andrew Flerchinger wrote: > On Mon, Mar 16, 2009 at 5:17 PM, Doug Barton <do...@dougbarton.us> wrote: >> Andrew Flerchinger wrote: >>> Yes, I do see that behavior. The primary difference is that I never want >>> it to prompt me for anything, since I'm writing a headless wrapper. >> What you're suggesting isn't "safe" in any case. What I would do in >> your situation is the following: >> >> 1. Use mktemp to safely create a new, unique file >> 2. Send the decryption output to that file >> 3. Test if the "real" file exists, and if so unlink it >> 4. mv $newfile $realfilename >> >> >> hth, >> >> Doug > > You're right, I could do that to make my work-around act atomic. Or > are you saying that even the functional encrypt behavior isn't "safe?"
For typical command line use by a real person I think it's just fine. If I were doing a script that used gpg in an unattended fashion I'd do the same thing for encrypt as I suggested for decrypt above. > I'm assuming that's essentially what gpg is already doing. Don't assume. Test. Depending on what you're using it for (and in what environment) the bar is much, much higher for programs (including scripts) that run in an automated environment than for those that run with real human interaction. Not that humans always make the right choices by any stretch. > I guess I'm still trying to determine the reason for the inconsistent > behavior between encryption and decryption functions. You're approaching this problem from the standpoint of unattended usage, which is not how the current command line behavior was intended. Doug _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
