[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exif --remove not idempotent, and a Debian man page bug



David Wright wrote:

>> But: isn't it still a bug in the distribution man page to
>> refer to mail address that bounces?
>
> I hope the maintainers (Debian's) have better things to do

Are you saying incorrect information in the man pages are OK
in Debian?

> than trawl through email addresses in man pages.

The fix in this case would amount to removing that entry from
the roff source.

>> exif(1) which says on line 57 that --remove
>> 
>>   Remove the tag or (if no tag is specified) the entire IFD.
>> 
>> Only if it does, why is it there the next time to be removed
>> as well?
>
> Have you tried it?

Yes, see the first post runs, they show that the same result
is obtained from running the same supposedly remove command on
the same files, 1, 2, and it would seem n number of times.

>> Maybe related to the '-o f f' part as your imagination
>> tells you ...
>
> Of course it is. Were there an option like --edit-in-place,
> then one might imagine risking writing to the same file, but
> there isn't.

What do you mean, how is one supposed to do it?

Write to a temp file and then move (overwrite) the original
with on the outside?

> Actually testing it shows that exif behaves as if the -o
> option is not there, and so you get a .modified.jpeg file.

No, in that case I would have .modified. img files over the
whole disk.

> It's up to you to overwrite the original.

You mean don't use the -o, or use the -o to point to a new
file, and then manually overwrite the old file with the
new one?

>>> In any case, if you want to file a Debian bug report, see
>>> <https://www.debian.org/Bugs/>.
>> 
>> Let's figure it out first, maybe.
>
> That wasn't difficult.

The man page reference is a bug, that mail bounces.

re: exif I don't know why processing happens again if the
material has already been removed. The '-o' shouldn't
matter since step one should be "is the material present?" and
if it isn't, nothing should be outputted. It should just say
"this file is already OK".

If '-o f f' _always_ fails that is a bug, the program should
catch that and don't do anything and just say "that isn't
supported, sorry. Instead do: XZY".

-- 
underground experts united
https://dataswamp.org/~incal


Reply to: