Andrew Flerchinger icrf.ml at gmail.com
wrote on Wed Mar 11 21:15:20 CET 2009 :
> My problem is when I don't tell it to overwrite
> and the target exists, it looks like it
> properly decrypted the file,
> except it does nothing
>I'm trying to figure out if I'm doing something wrong,
no, you'
On Thu, Mar 12, 2009 at 12:18 PM, wrote:
> Andrew Flerchinger icrf.ml at gmail.com
> wrote on Wed Mar 11 21:15:20 CET 2009 :
>
> > My problem is when I don't tell it to overwrite
> > and the target exists, it looks like it
> > properly decrypted the file,
> > except it does nothing
>
> >I'm tryin
Andrew Flerchinger icrf.ml at gmail.com
wrote on Mon Mar 16 14:10:31 CET 2009 :
> If I pass in --yes, it does indeed overwrite as I'd
> If I don't, it does NOT overwrite the file.
> it's just not telling me there was a problem with
> decryption like it does when I'm encrypting something.
th
On Mon, Mar 16, 2009 at 12:10 PM, wrote:
> Andrew Flerchinger icrf.ml at gmail.com
> wrote on Mon Mar 16 14:10:31 CET 2009 :
>
>
> > If I pass in --yes, it does indeed overwrite as I'd
> > If I don't, it does NOT overwrite the file.
>
> > it's just not telling me there was a problem with
> > decr
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 c
On Mon, Mar 16, 2009 at 5:17 PM, Doug Barton 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 d
Andrew Flerchinger wrote:
> On Mon, Mar 16, 2009 at 5:17 PM, Doug Barton 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" i
On Mon, Mar 16, 2009 at 5:59 PM, Doug Barton wrote:
> You're approaching this problem from the standpoint of unattended
> usage, which is not how the current command line behavior was intended.
>
>
> Doug
>
Okay, I can work around it in a satisfactory fashion. My personal
problem is solved.
Now,
Hi!
Andrew Flerchinger schrieb:
>> 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
>>
> You're right, I could do that to make my work-around act atomic.
Be
