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

[Emanuel Berg]

>From IRC ...

<incal> vengeance, you the exif(1) guy here, right, how
can it be it isn't idempotent? I just run it for
every jpg on the HDD and after done, it does the
same thing again upon a 2nd invocation

<incal> I'll mail Lutz Mueller <lu...@users.sourceforge.net> as well

<incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
file' | wc -l # 2277 (1st invocation)

<incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
file' | wc -l # 2277 (2nd invocation)

<incal> ??

<incal> ah that mail is 550

<incal> unknown user

<incal> let's post it on gmane.linux.debian.user then ...

<incal> Debian should remove that from the man page then, i.e. exif(1)

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

[Greg Wooledge]

On Wed, Sep 21, 2022 at 09:02:09AM +0200, Emanuel Berg wrote:
> <incal> I'll mail Lutz Mueller <lu...@users.sourceforge.net> as well

According to the package metadata, the Debian maintainer of exif is:

Maintainer: Debian PhotoTools Maintainers <pkg-photot...@lists.alioth.debian.org>

> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
> file' | wc -l # 2277 (1st invocation)

I hope you're not using bash here. If you are, the "$f" instances need
to be double-quoted, or else this is going to fail spectacularly on
filenames with whitespace or globbing characters.

Of course, ** doesn't work by default in bash; you have to enable it with
shopt -s globstar beforehand. The fact that you didn't show this step,
however, doesn't prove you're in a non-bash shell.

> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
> file' | wc -l # 2277 (2nd invocation)

I don't know what the intended behaviof of "exif --remove -o file file"
is. I'm imagining that it's like "sed -i" which always opens and writes
a new instance of the file, even if no changes are made.

> <incal> Debian should remove that from the man page then, i.e. exif(1)

Remove what? Perhaps what you actually want is additional clarity
about how the --remove option (or the -o option) works.

In any case, if you want to file a Debian bug report, see
<https://www.debian.org/Bugs/>.

[Emanuel Berg]

Greg Wooledge wrote:

> According to the package metadata, the Debian maintainer of
> exif is:

OK, cool.

> Maintainer: Debian PhotoTools Maintainers
> <pkg-photot...@lists.alioth.debian.org>

They are CC'd, let's see what they say.

But: isn't it still a bug in the distribution man page to
refer to mail address that bounces?

>> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
>> file' | wc -l # 2277 (1st invocation)
>
> I hope you're not using bash here. If you are, the "$f"
> instances need to be double-quoted, or else this is going to
> fail spectacularly on filenames with whitespace or
> globbing characters.

zsh.

> I don't know what the intended behaviof of "exif --remove -o

> file file" is. I'm imagining [...]

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?

Maybe related to the '-o f f' part as your imagination
tells you ...

> 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.

[David Wright]

On Wed 21 Sep 2022 at 14:46:55 (+0200), Emanuel Berg wrote:
> Greg Wooledge wrote:
>
> > According to the package metadata, the Debian maintainer of
> > exif is:
>
> OK, cool.
>
> > Maintainer: Debian PhotoTools Maintainers
> > <pkg-photot...@lists.alioth.debian.org>
>
> They are CC'd, let's see what they say.
>
> 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 than trawl
through email addresses in man pages. The man page has its origin and
date clearly indicated. The web and its search engines are still there.

> >> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
> >> file' | wc -l # 2277 (1st invocation)
> >
> > I hope you're not using bash here. If you are, the "$f"
> > instances need to be double-quoted, or else this is going to
> > fail spectacularly on filenames with whitespace or
> > globbing characters.
>
> zsh.

It would be polite to say that, as I think we're entitled to assume
bash unless otherwise indicted. (Perhaps dash, if it's a script
belonging to the system.)

> > I don't know what the intended behaviof of "exif --remove -o
> > file file" is. I'm imagining [...]
>
> 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?

> 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.

Actually testing it shows that exif behaves as if the -o
option is not there, and so you get a .modified.jpeg file.
It's up to you to overwrite the original.

> > 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.

Cheers,
David.

[Emanuel Berg]

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".

[Greg Wooledge]

On Fri, Sep 23, 2022 at 04:14:43PM +0200, Emanuel Berg wrote:
> The fix in this case would amount to removing that entry from
> the roff source.

Let's be clear. We're talking about the exif(1) man page, as shown
here?


https://manpages.debian.org/bullseye/exif/exif.1.en.html

AUTHOR
exif was written by Lutz Mueller <lu...@users.sourceforge.net> and
numerous contributors. This man page is Copyright © 2002-2012 Thomas
Pircher, Dan Fandrich and others.


This isn't a contact address for bug reports. It's a historical note.

[Emanuel Berg]

Greg Wooledge wrote:

> https://manpages.debian.org/bullseye/exif/exif.1.en.html
>
> AUTHOR
> exif was written by Lutz Mueller
> <lu...@users.sourceforge.net> and numerous contributors.
> This man page is Copyright © 2002-2012 Thomas Pircher,
> Dan Fandrich and others.
>
> This isn't a contact address for bug reports.
> It's a historical note.

Indeed, that e-mail belongs to history, which is why it should
be removed from actively deployed documentation concerning
a tool that's very much in use.

[The Wanderer]

On 2022-09-23 at 11:07, Emanuel Berg wrote:

> Greg Wooledge wrote:
>
>> https://manpages.debian.org/bullseye/exif/exif.1.en.html
>>
>> AUTHOR
>> exif was written by Lutz Mueller
>> <lu...@users.sourceforge.net> and numerous contributors.
>> This man page is Copyright © 2002-2012 Thomas Pircher,
>> Dan Fandrich and others.
>>
>> This isn't a contact address for bug reports.
>> It's a historical note.
>
> Indeed, that e-mail belongs to history, which is why it should
> be removed from actively deployed documentation concerning
> a tool that's very much in use.

Look at the end of the man page for 'man' itself:

>>> HISTORY
>>> 1990, 1991 – Originally written by John W. Eaton (j...@che.utexas.edu).
>>>
>>> Dec 23 1992: Rik Faith (fa...@cs.unc.edu) applied bug fixes supplied by
>>> Willem Kasdorp (wka...@nikhefk.nikef.nl).
>>>
>>> 30th April 1994 – 23rd February 2000: Wilf. (G.Wi...@ee.surrey.ac.uk)
>>> has been developing and maintaining this package with the help of a few
>>> dedicated people.
>>>
>>> 30th October 1996 – 30th March 2001: Fabrizio Polacco <fpolacco@de‐
>>> bian.org> maintained and enhanced this package for the Debian project,
>>> with the help of all the community.
>>>
>>> 31st March 2001 – present day: Colin Watson <cjwa...@debian.org> is
>>> now developing and maintaining man-db.

That's maintainership history, with E-mail addresses attached.

'man dpkg' points to /usr/share/doc/dpkg/THANKS (which in practice has a
.gz extension), which is a long, long list of people who contributed to
dpkg, each one with an E-mail address attached. That's historical
information, with E-mail addresses, which is shipped with the package
and cited in the man page even if not included directly there.

'man ls' references RMS and David MacKenzie as the original authors,
although it doesn't give E-mail addresses for them. (While it's possible
they're the active upstream maintainers, I would be slightly surprised
to learn that.)

'man bash' cites Brian Fox and Chet Ramey as the authors, and gives an
E-mail address for each. (It's possible that they may be the active
upstream maintainers, as well.)

There are almost certainly other examples to be found.

Including historical information in the man page about who originally
wrote a program is not at all outside the range of normal practice, and
including E-mail addresses with that is also within reasonable scope.
Omitting such is also not outside of scope, but it's not remotely close
to being mandatory.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Greg Wooledge]

On Fri, Sep 23, 2022 at 11:22:31AM -0400, The Wanderer wrote:
> 'man bash' cites Brian Fox and Chet Ramey as the authors, and gives an
> E-mail address for each. (It's possible that they may be the active
> upstream maintainers, as well.)

Chet Ramey is the current upstream bash maintainer. Brian Fox has not
been involved with bash development for decades. Nevertheless, removing
Brian's email address from the AUTHORS section is neither necessary nor
desirable. Everyone knows it's a historical section.

In the case of the bash(1) page, it's actually followed by a BUG REPORTS
section, telling you how to submit bug reports to the upstream maintainer.
That's not common in man pages, but clearly not unheard of either.

As a Debian user, however, one is expected to know how to file bug reports
correctly. It is NOT done by trudging through the man page looking for
the first email address one can find. It's done by using the reportbug
tool, or by following the instructions on the <https://bugs.debian.org/>
web site.

[The Wanderer]

To be fair, some types of bug you're recommended to report upstream
instead, and for those looking at an E-mail address identified in the
man page as being related to upstream is not a terribly unreasonable
idea (albeit, as shown here, not always a fruitful one).

[Emanuel Berg]

The Wanderer wrote:

> That's maintainership history, with E-mail
> addresses attached.

There should be no history entries in the man pages that
relates to practical aspects that are no longer operational.

Commands, examples that once worked but are now removed,
options that are obsolete/deprecated, or indeed e-mails that
bounces and thus cannot be used, none of that has any place,
anywhere, in the man pages.

The man pages should be about the tool today, and history
notes should be allowed only so far as they don't reduce the
practical usefulness of the documentation and by extension
tool use itself.

This whole discussion is an example of why you don't want
incorrect information in documentation. To me, that's pretty
clear without an example, but if you need one to use in
discussion, feel free to use this. "Here is what happens, if
you include incorrect tech information in manpages and think
that is OK."

[Emanuel Berg]

Greg Wooledge wrote:

>> 'man bash' cites Brian Fox and Chet Ramey as the authors,
>> and gives an E-mail address for each. (It's possible that
>> they may be the active upstream maintainers, as well.)
>
> Chet Ramey is the current upstream bash maintainer.
> Brian Fox has not been involved with bash development for
> decades. Nevertheless, removing Brian's email address from
> the AUTHORS section is neither necessary nor desirable.
> Everyone knows it's a historical section.

I think it's wrong to include tech information in manpages
that looks useful but isn't, I'd consider that a bug which
should and could be fixed quickly and easily.

I didn't know this was a radical view actually! But I take
pride in this, apparently controversial position then.

[The Wanderer]

On 2022-09-23 at 12:02, Emanuel Berg wrote:

> The Wanderer wrote:
>
>> That's maintainership history, with E-mail addresses attached.
>
> There should be no history entries in the man pages that relates to
> practical aspects that are no longer operational.

The E-mail address doesn't relate to a practical aspect, though.

It's part of the identifying information for the person being
referenced. There might well be multiple people out there in the world
with that name, but only one of them has (or used to have) that E-mail
address.

Do you extend this to say that the man page shouldn't mention former
maintainers who are no longer involved with the program?

> Commands, examples that once worked but are now removed, options that
> are obsolete/deprecated, or indeed e-mails that bounces and thus
> cannot be used, none of that has any place, anywhere, in the man
> pages.
>
> The man pages should be about the tool today, and history notes
> should be allowed only so far as they don't reduce the practical
> usefulness of the documentation and by extension tool use itself.
>
> This whole discussion is an example of why you don't want incorrect
> information in documentation.

It's not incorrect, though. It just doesn't mean what you appear to have
thought it meant.

> To me, that's pretty clear without an example, but if you need one to
> use in discussion, feel free to use this. "Here is what happens, if
> you include incorrect tech information in manpages and think that is
> OK."

This isn't technical information, though; it's historical and
identifying information.

[Alex King]

On 24/09/22 03:32, Greg Wooledge wrote:
> On Fri, Sep 23, 2022 at 11:22:31AM -0400, The Wanderer wrote:
>> 'man bash' cites Brian Fox and Chet Ramey as the authors, and gives an
>> E-mail address for each. (It's possible that they may be the active
>> upstream maintainers, as well.)
>
> Chet Ramey is the current upstream bash maintainer. Brian Fox has not
> been involved with bash development for decades. Nevertheless, removing
> Brian's email address from the AUTHORS section is neither necessary nor
> desirable. Everyone knows it's a historical section.
>

I've been using Debian as my main OS since 1997 or earlier. I've spent
100s of hours reading man pages. Although it's a reasonable assumption
(since there are a lot of man pages with outdated AUTHORS sections), I
didn't know the AUTHORS section is supposed to be an historical record.

Have you got a reference to that somewhere? After all (some) man pages
have a HISTORY section for historical information.

> In the case of the bash(1) page, it's actually followed by a BUG REPORTS
> section, telling you how to submit bug reports to the upstream maintainer.
> That's not common in man pages, but clearly not unheard of either.
>
> As a Debian user, however, one is expected to know how to file bug reports
> correctly. It is NOT done by trudging through the man page looking for
> the first email address one can find. It's done by using the reportbug
> tool, or by following the instructions on the <https://bugs.debian.org/>
> web site.

Again, I sometimes report bugs to Debian and sometimes to upstream, and
occasionally email maintainers directly, especially if I can't work out
if any upstream still exists and especially if the software is not (any
longer) in Debian.

How is it expected that a new user will have learnt "how to file bug
reports correctly?" What is the typical path for a Debian user to pick
up that knowledge? What even is the correct way to report bugs, and
where is that documented? I see https://www.debian.org/Bugs/Reporting,
which mentions "Don't file bugs upstream, if you file a bug in Debian"
Perhaps you can point to some documentation discussing whether to report
a bug to Debian or through other channels. Or perhaps a statement
recommending (particularly newbies) to report all bugs direct to Debian.
It seems to be implied, but I didn't see where it was stated explicitly.

I see at https://www.debian.org/support, that after IRC, this list is
the second channel mentioned for people seeking support with Debian.

I believe using phrases like "Everyone knows it's a historical section."
when the OP didn't seem to know that, and "one is expected to know how"
is not particularly helpful. Especially on the channel that is the
first (usable) point of contact for new users seeking support, if they
are not familiar with IRC.

Greg, I'm wondering if you would consider using more friendly and
inclusive language on the debian-user list? So that it's less
off-putting to newbies (in general, regardless of whether the OP is a
newbie.)

In relation to man pages, perhaps everyone could agree that ideally
historical email addresses could be removed from the AUTHORS section and
moved to a HISTORY section. I'm sure we can all agree this should not
be mandatory, but those who feel most strongly about it could contribute
patches...

--
Thanks,
Alex King

[hede]

Am 21.09.2022 14:46, schrieb Emanuel Berg:
>> I don't know what the intended behaviof of "exif --remove -o
>> file file" is. I'm imagining [...]
>
> exif(1) which says on line 57 that --remove
>
> Remove the tag or (if no tag is specified) the entire IFD.

"Idempotent" means, that a task with the same input data and the same
config (for example to remove a tag via exif-tool) results in the same
output data. Is this the case here?

>
> Only if it does, why is it there the next time to be removed
> as well?
>
> Maybe related to the '-o f f' part as your imagination
> tells you ...

The "-o" means: "Write output image to FILE". And it does so, as far as
I can see.

hede

[Greg Wooledge]

The question is whether specifying "-o f f" where the output file
has the same name as the input file actually overwrites the original
input file. Another person reported that it does *not* -- that you get
a *.modified.jpeg file as output instead.

If I had the first inkling of a clue what an exif tag actually *was* I
might try testing it myself. I'm gathering that it has something to do
with JPEG images, based on the *.modified.jpeg default output filename.
Beyond that, I know nothing.

One of you people who knows this software and has a testable input file
should (please!) try it, and show us the results. Make an empty
directory. Copy the JPEG file into it. Show "ls -l" output. Run the
exif command. Show "ls -l" again.

[Curt]

On 2022-09-24, Alex King <al...@rimuhosting.com> wrote:
>
>
> I've been using Debian as my main OS since 1997 or earlier. I've spent
> 100s of hours reading man pages. Although it's a reasonable assumption
> (since there are a lot of man pages with outdated AUTHORS sections), I
> didn't know the AUTHORS section is supposed to be an historical record.
>

How can an AUTHORS section be outdated? F. Scott Fitzgerald is dead,
and fan mail will fail to reach him, but he remains the author of *The
Great Gatsby*.

[David Wright]

On Sat 24 Sep 2022 at 10:43:04 (-0400), Greg Wooledge wrote:
> On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> > Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > > Maybe related to the '-o f f' part as your imagination
> > > tells you ...
> >
> > The "-o" means: "Write output image to FILE". And it does so, as far as I
> > can see.
>
> The question is whether specifying "-o f f" where the output file
> has the same name as the input file actually overwrites the original
> input file. Another person reported that it does *not* -- that you get
> a *.modified.jpeg file as output instead.

That was me, and I think I used the wrong file to test (IFD had been
stripped already), and I think I confused the output from several
runs (I hadn't used exif before, excepting a while back, when I
determined that it couldn't read the photos off my Samsung Gusto2
mobile, which means it's useless for me).

> If I had the first inkling of a clue what an exif tag actually *was* I
> might try testing it myself. I'm gathering that it has something to do
> with JPEG images, based on the *.modified.jpeg default output filename.
> Beyond that, I know nothing.
>
> One of you people who knows this software and has a testable input file
> should (please!) try it, and show us the results. Make an empty
> directory. Copy the JPEG file into it. Show "ls -l" output. Run the
> exif command. Show "ls -l" again.

I showed the EXIF itself instead.

Cheers,
David.

[David Wright]

On Fri 23 Sep 2022 at 16:14:43 (+0200), Emanuel Berg wrote:

> David Wright wrote:
> >> 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.

I made an error in my testing, in that I think I used a
(published) stripped jpeg for the same-filename test.

Using a photograph from my own archives shows that --remove
is stripping the IFD and -o foo foo is overwriting the
original file, though I don't know what its mechanism is
(one hopes it makes safeguards).

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

Yes, that would seem to be correct.

> > 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?

To be honest, I don't use exif but exifprobe -L, and I wouldn't
want to make modifications without keeping modified copies in a
separate tree (I've done this for lower resolution publication
on web pages). I can see why you might be doing the same sort
of thing (perhaps for tree-houses?).

BTW exif can't read photos off a Samsung Gusto2 mobile.

> re: exif I don't know why processing happens again if the
> material has already been removed.

It wouldn't be the first filter program to behave in this way.

> 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".

That would be asking a filter program to treat the construction
--remove -o foo foo as a unique case, where it conditionally
doesn't write an output file.

Anyway, here's a test on an old photograph of mine:

$ exif 2005-05-24-18-20-44.jpg
EXIF tags in '2005-05-24-18-20-44.jpg' ('Intel' byte order):
--------------------+----------------------------------------------------------
Tag |Value
--------------------+----------------------------------------------------------
Image Description |000001
Manufacturer |FUJIFILM
Model |DS-300
Orientation |Top-left
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
White Point |0.3127, 0.3290
Primary Chromaticiti|0.640, 0.330, 0.300, 0.600, 0.150, 0.060
YCbCr Coefficients |0.299, 0.587, 0.114
YCbCr Positioning |Co-sited
Reference Black/Whit| 0, 255, 128, 255, 128, 255
Exif Version |Exif Version 1.1
Date and Time (Origi|2005:05:24 18:20:43
Components Configura|Y Cb Cr -
Compressed Bits per | 2
Shutter Speed |6.50 EV (1/91 sec.)
Aperture |3.50 EV (f/3.4)
FlashPixVersion |FlashPix Version 1.0
Color Space |Uncalibrated
--------------------+----------------------------------------------------------
$ exif --remove -o 2005-05-24-18-20-44.jpg 2005-05-24-18-20-44.jpg
Wrote file '2005-05-24-18-20-44.jpg'.
$ exif 2005-05-24-18-20-44.jpg
EXIF tags in '2005-05-24-18-20-44.jpg' ('Intel' byte order):
--------------------+----------------------------------------------------------
Tag |Value
--------------------+----------------------------------------------------------
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
Exif Version |Exif Version 2.1
FlashPixVersion |FlashPix Version 1.0
Color Space |Uncalibrated
--------------------+----------------------------------------------------------
$ exif --remove -o 2005-05-24-18-20-44.jpg 2005-05-24-18-20-44.jpg
Wrote file '2005-05-24-18-20-44.jpg'.
$ exif 2005-05-24-18-20-44.jpg
EXIF tags in '2005-05-24-18-20-44.jpg' ('Intel' byte order):
--------------------+----------------------------------------------------------
Tag |Value
--------------------+----------------------------------------------------------
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
Exif Version |Exif Version 2.1
FlashPixVersion |FlashPix Version 1.0
Color Space |Uncalibrated
--------------------+----------------------------------------------------------
$

… idempotent ad infinitum.

Cheers,
David.

[David Wright]

On Sat 24 Sep 2022 at 12:13:09 (+1200), Alex King wrote:
> On 24/09/22 03:32, Greg Wooledge wrote:
> > On Fri, Sep 23, 2022 at 11:22:31AM -0400, The Wanderer wrote:
> > > 'man bash' cites Brian Fox and Chet Ramey as the authors, and gives an
> > > E-mail address for each. (It's possible that they may be the active
> > > upstream maintainers, as well.)
> >
> > Chet Ramey is the current upstream bash maintainer. Brian Fox has not
> > been involved with bash development for decades. Nevertheless, removing
> > Brian's email address from the AUTHORS section is neither necessary nor
> > desirable. Everyone knows it's a historical section.
> >
> I've been using Debian as my main OS since 1997 or earlier. I've
> spent 100s of hours reading man pages. Although it's a reasonable
> assumption (since there are a lot of man pages with outdated AUTHORS
> sections), I didn't know the AUTHORS section is supposed to be an
> historical record.
>
> Have you got a reference to that somewhere? After all (some) man
> pages have a HISTORY section for historical information.

Unless you come up with a patch to do this, and maintain it to cope
with upstream modifications, you're at the mercy of the upstream
and, of course, the Author.

> > In the case of the bash(1) page, it's actually followed by a BUG REPORTS
> > section, telling you how to submit bug reports to the upstream maintainer.
> > That's not common in man pages, but clearly not unheard of either.
> >
> > As a Debian user, however, one is expected to know how to file bug reports
> > correctly. It is NOT done by trudging through the man page looking for
> > the first email address one can find. It's done by using the reportbug
> > tool, or by following the instructions on the <https://bugs.debian.org/>
> > web site.
>
> Again, I sometimes report bugs to Debian and sometimes to upstream,
> and occasionally email maintainers directly, especially if I can't
> work out if any upstream still exists and especially if the software
> is not (any longer) in Debian.
>
> How is it expected that a new user will have learnt "how to file bug
> reports correctly?" What is the typical path for a Debian user to
> pick up that knowledge? What even is the correct way to report bugs,
> and where is that documented? I see
> https://www.debian.org/Bugs/Reporting, which mentions "Don't file bugs
> upstream, if you file a bug in Debian" Perhaps you can point to some
> documentation discussing whether to report a bug to Debian or through
> other channels. Or perhaps a statement recommending (particularly
> newbies) to report all bugs direct to Debian. It seems to be implied,
> but I didn't see where it was stated explicitly.

Typically, the maintainer is given in several places, like the Bugs
page, the Packages page, the Tracker page, and the Packages file.
The last of these gives the URL of the software's home page as well.

> I see at https://www.debian.org/support, that after IRC, this list is
> the second channel mentioned for people seeking support with Debian.
>
> I believe using phrases like "Everyone knows it's a historical
> section." when the OP didn't seem to know that, and "one is expected
> to know how" is not particularly helpful. Especially on the channel
> that is the first (usable) point of contact for new users seeking
> support, if they are not familiar with IRC.
>

[ … ]

>
> In relation to man pages, perhaps everyone could agree that ideally
> historical email addresses could be removed from the AUTHORS section
> and moved to a HISTORY section. I'm sure we can all agree this should
> not be mandatory, but those who feel most strongly about it could
> contribute patches...

Good to see that they're identifying themselves here :)

Cheers,
David.

[Emanuel Berg]

The Wanderer wrote:

>>> That's maintainership history, with E-mail
>>> addresses attached.
>>
>> There should be no history entries in the man pages that
>> relates to practical aspects that are no
>> longer operational.
>
> The E-mail address doesn't relate to a practical
> aspect, though.

Ikr? Since it doesn't work! Just remove it.

[Emanuel Berg]

Greg Wooledge wrote:

>> The "-o" means: "Write output image to FILE". And it does
>> so, as far as I can see.
>
> The question is whether specifying "-o f f" where the output file
> has the same name as the input file actually overwrites the original
> input file. Another person reported that it does *not* -- that you get
> a *.modified.jpeg file as output instead.

Does happen _without_ -o ...

> If I had the first inkling of a clue what an exif tag
> actually *was* I might try testing it myself. I'm gathering
> that it has something to do with JPEG images, based on the
> *.modified.jpeg default output filename. Beyond that,
> I know nothing.
>
> One of you people who knows this software and has a testable
> input file should (please!) try it, and show us the results.

See the first post ...

[Emanuel Berg]

hede wrote:

> "Idempotent" means, that a task with the same input data and
> the same config (for example to remove a tag via exif-tool)
> results in the same output data.

Determinism.

[The Wanderer]

On 2022-09-25 at 01:43, Emanuel Berg wrote:

> The Wanderer wrote:

>>> There should be no history entries in the man pages that
>>> relates to practical aspects that are no
>>> longer operational.
>>
>> The E-mail address doesn't relate to a practical
>> aspect, though.
>
> Ikr? Since it doesn't work! Just remove it.

It does work: it works to identify which of the people with the
referenced name is the one who is being referred to, because only one of
those people either has or formerly had that address.

As I said in the part you snipped, it is *identifying* information.

[rhkr...@gmail.com]

On Saturday, September 24, 2022 09:17:31 AM hede wrote:

> "Idempotent" means, that a task with the same input data and the same

> config (for example to remove a tag via exif-tool) results in the same

> output data. Is this the case here?

 

That is not my understanding of itempotent (nor of Wikipedia). A succinct quote from another source:

 

<quote>

An operation that produces the same results no matter how many times it is performed.

</quote>

 

Some examples from (simple) math include adding zero or multiplying by 1. An example from "real life" could be pressing the on (or off) button on some electronic device.

 

--

rhk

 

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; avoid top posting; and keep it "on list". (Oxford comma included at no charge.) If you change topics, change the Subject: line.

 

Writing is often meant for others to read and understand (legal agreements excepted?) -- make it easier for your reader by various means, including liberal use of whitespace and minimal use of (obscure?) jargon, abbreviations, acronyms, and references.

 

If someone else has already responded to a question, decide whether any response you add will be helpful or not ...

 

A picture is worth a thousand words -- divide by 10 for each minute of video (or audio) or create a transcript and edit it to 10% of the original.

 

[rhkr...@gmail.com]

Oops, ignore that previous response ...

On second thought, what hede wrote is correct, it is just stated in a way that
I wasn't famiiar with (and I haven't had my morning coffee yet)

Sorry for the noise!

[The Wanderer]

On 2022-09-25 at 08:22, rhkr...@gmail.com wrote:

> Oops, ignore that previous response ...
>
> On second thought, what hede wrote is correct, it is just stated in a
> way that I wasn't famiiar with (and I haven't had my morning coffee
> yet)

Are you sure?

Because it doesn't seem to match my understanding of the meaning of the
word, and what you gave as an alternative seems closer.


If I had to describe the concept of idempotence, I might choose
something like:

Take object A.

Apply it as input to operation O, and get object B as output.

Take object B, apply it as input to operation O, and get object C as output.

If the nature of operation O is such that objects B and C are guaranteed
to always be identical, no matter what object A was, then operation O is
categorized as being idempotent.


That's not producing the same output with the same input (which is how I
read the explanation that hede gave); that's producing the same output
with both the original input *and* the output obtained by processing
that original input.


The definitions found in foldoc and in the Jargon File seem compatible
with that.

[hede]

Am 25.09.2022 14:42, schrieb The Wanderer:
> On 2022-09-25 at 08:22, rhkr...@gmail.com wrote:
>
>> On second thought, what hede wrote is correct, it is just stated in a
>> way that I wasn't famiiar with (and I haven't had my morning coffee
>> yet)
>
> Are you sure?

Meanwhile, I do think my description was not correct. Sorry for that.
But probably the tool matches the definition, if it writes the same data
in the second run. ;-)

((( off topic addition:

On 2022-09-25 at 08:22, rhkr...@gmail.com wrote

> [...]
> <quote>
> [...]
> </quote>
> [...]
> If you reply: [...] avoid HTML; [...]

I love this kind of humor ;-)

)))

[Emanuel Berg]

rhkramer wrote:

> An operation that produces the same results no matter how
> many times it is performed.

Yeah, obviously it is a term from math and in practical and
applied engineering as is programming I thought of
a definition (not really) like this

- apply once, you get the change

- apply twice, thrice, or n'ice, nothing happens since the
change happened the first time and there is nothing to do

Stefan and Tomás can tell I know...

Anyway in math everyone understands it, and an example is the
absolute value,

abs(x) = ...

abs(abs(x)) = ...

abs..(abs(abs(x))) = ...

Same!

And that's pretty close to what I just said.

The difference if any seems to be, in math focus is on the
return value, so it is easy - is it the same or not?

Im programming, focus is "can I apply it to make sure the job
is done, and don't have to think - has it already been done? -
because if so, no matter how many times, it won't ruin it,
just nothing will happen over and over and whatever stuff it
is applied on will be in the after-applied, desired form".

That's right, right? Or am I wrong?

[Emanuel Berg]

The Wanderer wrote:

> If the nature of operation O is such that objects B and
> C are guaranteed to always be identical, no matter what
> object A was, then operation O is categorized as
> being idempotent.

It has to do with the number of times it is applied,

abs(x) = abs(abs(x)) = abs..(abs(abs(x)))

The same!

This is the math definition, my use case of the word was
applied programming so it cannot be _exactly_ like that.

Well, maybe in Haskell it can ...

[debia...@howorth.org.uk]

Sorry, but what's the practical point of all this discussion?

[David Wright]

On Sun 25 Sep 2022 at 07:52:38 (+0200), Emanuel Berg wrote:
> Greg Wooledge wrote:

> > If I had the first inkling of a clue what an exif tag
> > actually *was* I might try testing it myself. I'm gathering
> > that it has something to do with JPEG images, based on the
> > *.modified.jpeg default output filename. Beyond that,
> > I know nothing.
> >
> > One of you people who knows this software and has a testable
> > input file should (please!) try it, and show us the results.
>
> See the first post ...

The OP didn't contain any exif output, only a couple of command
lines, apparently written in zsh shell, and some chit-chat.

The focus of the thread seems to have changed to the meaning of
a word in the Subject, and an old email address that might help
in distinguishing Lutz Mueller from all the other Lutz Muellers.

Cheers,
David.

[Emanuel Berg]

David Wright wrote:

>> See the first post ...
>
> The OP didn't contain any exif output, only a couple of
> command lines, apparently written in zsh shell

Look again!

> The focus of the thread seems to have changed to the meaning
> of a word in the Subject, and an old email address that
> might help in distinguishing Lutz Mueller from all the other
> Lutz Muellers.

I have now clarified to the best of my ability the meaning of
that word and I think that will help people understand at last
why incorrect tech information, actually disinformation at
that point, can't be allowed in software documentation. I get
it now that this was the root of the confusion but as always
everything in time ...

[Curt]

On 2022-09-25, Emanuel Berg <in...@dataswamp.org> wrote:
> The Wanderer wrote:
>
>> If the nature of operation O is such that objects B and
>> C are guaranteed to always be identical, no matter what
>> object A was, then operation O is categorized as
>> being idempotent.
>
> It has to do with the number of times it is applied,
>
> abs(x) = abs(abs(x)) = abs..(abs(abs(x)))

That's the example given on the Wikipedia page on the subject, I think.
It has the merit of being comprehensible even to me.

> The same!
>
> This is the math definition, my use case of the word was
> applied programming so it cannot be _exactly_ like that.

One "programming" example given on that same Wikipedia page was that if
you applied an update operation to Lutz Mueller's email address in a
database (*ich habe Kopfschmerzen*!) that same update applied a second
or third time (ad infinitum) would produce identical results.

[rhkr...@gmail.com]

On Sunday, September 25, 2022 08:42:57 AM The Wanderer wrote:
> On 2022-09-25 at 08:22, rhkr...@gmail.com wrote:
> > Oops, ignore that previous response ...
> >
> > On second thought, what hede wrote is correct, it is just stated in a
> > way that I wasn't famiiar with (and I haven't had my morning coffee
> > yet)
>
> Are you sure?

No ;-)

I'm sure that what I wrote is correct (e.g., as simple examples,
multiplication by 1 or addition of 0), and I'm sure what you wrote (below) is
correct, but I had trouble interpreting Hede's words, and eventually decided
that maybe what he said is equivalent but using different words.

I'm not going to go back and look at his words again atm, but even if they are
correct, I don't like them, it is too difficult (for me ;-) to interpret them /
read them as equivalent to other (correct) definitions of idempotent (like
yours, mine, Wikipedia's, and others that have been mentioned on the list).

I'm debating whether this is worth sending this to the list or if will just
contribute to the noise (and somehow "justify" my two previous responses) -- I
wrote it so I'll probably send it, although I could instead send it just to
you (The Wanderer).

Sending to the list.

>
> Because it doesn't seem to match my understanding of the meaning of the
> word, and what you gave as an alternative seems closer.
>
>
> If I had to describe the concept of idempotence, I might choose
> something like:
>
> Take object A.
>
> Apply it as input to operation O, and get object B as output.
>
> Take object B, apply it as input to operation O, and get object C as
> output.
>
> If the nature of operation O is such that objects B and C are guaranteed
> to always be identical, no matter what object A was, then operation O is
> categorized as being idempotent.
>
>
> That's not producing the same output with the same input (which is how I
> read the explanation that hede gave); that's producing the same output
> with both the original input *and* the output obtained by processing
> that original input.
>
>
> The definitions found in foldoc and in the Jargon File seem compatible
> with that.

--

[David Wright]

On Mon 26 Sep 2022 at 07:42:16 (+0200), Emanuel Berg wrote:
> David Wright wrote:
>
> >> See the first post ...
> >
> > The OP didn't contain any exif output, only a couple of
> > command lines, apparently written in zsh shell
>
> Look again!

Look at it? I'll quote it in full (attached).

> > The focus of the thread seems to have changed to the meaning
> > of a word in the Subject, and an old email address that
> > might help in distinguishing Lutz Mueller from all the other
> > Lutz Muellers.
>
> I have now clarified to the best of my ability the meaning of
> that word and I think that will help people understand at last
> why incorrect tech information, actually disinformation at
> that point, can't be allowed in software documentation. I get
> it now that this was the root of the confusion but as always
> everything in time ...

Please—there's no malicious content in the man page.
The attribution was true at the time it was written, and
is clearly dated. If the author had given a street address
(as used to be the case in the past), since demolished,
or had retired from writing software, or was deceased,
that doesn't change the authorship.

And if you dispute the man page, you might be more
concerned about its author and copyright holders,
rather than the author of the software itself.

Cheers,
David.

[Emanuel Berg]

mick.crane wrote:

>> I have now clarified to the best of my ability the meaning
>> of that word and I think that will help people understand
>> at last why incorrect tech information, actually
>> disinformation at that point, can't be allowed in software
>> documentation. I get it now that this was the root of the
>> confusion but as always everything in time ...
>

> Yes but an Oxford comma.

What are you, an English Mayor?

No ... it should be with a j, right?

Okay, let's try: "I think it's understandable the way I put
it, but language is a tool and should for that reason ALWAYS
be used correctly. To the letter, even?"

[Emanuel Berg]

David Wright wrote:

>>>> See the first post ...
>>>
>>> The OP didn't contain any exif output, only a couple of
>>> command lines, apparently written in zsh shell
>>
>> Look again!
>
> Look at it? I'll quote it in full (attached).

Look more, quote less ...

<incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
file' | wc -l # 2277 (1st invocation)

<incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
file' | wc -l # 2277 (2nd invocation)

> Please—there's no malicious content in the man page.

Yeah, and that makes sense. I heard of an initiative to add
support for fake news to Emacs Gnus. Cool, but to have it in
the man pages? Not only are they relied upon for practical
purposes every day literally all over the world, they are also
iconic, almost, so associated and in a positive way with Unix
and everything it stands for.

You are aware the OpenBSD people always brag they have the
best documentation?

Maybe they do, it's hard to say, but clear cases like this
should just be pruned immediately so at least they have to
earn it ...

> The attribution was true at the time it was written, and is
> clearly dated. If the author had given a street address

Haha, what? :P street address? ??? I refer to the
EMAIL address!

[Greg Wooledge]

On Mon, Sep 26, 2022 at 09:07:29PM +0200, Emanuel Berg wrote:
> David Wright wrote:
>
> >>>> See the first post ...
> >>>
> >>> The OP didn't contain any exif output, only a couple of
> >>> command lines, apparently written in zsh shell
> >>
> >> Look again!
> >
> > Look at it? I'll quote it in full (attached).
>
> Look more, quote less ...
>
> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
> file' | wc -l # 2277 (1st invocation)
>
> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep 'Wrote
> file' | wc -l # 2277 (2nd invocation)

There is NO exif output in that message.

The only "output" there is from wc -l, and it's you typing it as a comment
after the shell command, not even showing it properly.

The entire thread was a result of your assumption that exif would NOT write
the words "Wrote file" if the input file had no exif tag in it. This turned
out to be false. exif writes those words every time.

A simple test on your part, with one file, would have revealed that.

Problem solved. Now can you just STOP? I'm getting THOROUGHLY sick of
the incorrect pedantry and the noise.

[Emanuel Berg]

Curt wrote:

> One "programming" example given on that same Wikipedia page
> was that if you applied an update operation to Lutz
> Mueller's email address in a database (*ich habe
> Kopfschmerzen*!) that same update applied a second or third
> time (ad infinitum) would produce identical results.

Yeah, but the same thing applied in the same context _always_
produce the same result in computing, this property is
called determinism. The Eagle has landed, maybe, but my
computer is still deterministic, thanks god :)

In programming the focus is perhaps better, for something
idempotent, something like: Do it the first time. Don't screw
it up the second time? And don't do the computing if it
doesn't need to be done?

The definition of insanity OTOH is trying the same thing over
and over, each time getting a different result ... (General Lee)

Or Manny Pacquiao vs Juan Manuel Márquez I-IV ...

[Emanuel Berg]

Greg Wooledge wrote:

>> Look more, quote less ...
>>
>> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> 'Wrote
>> file' | wc -l # 2277 (1st invocation)
>>
>> <incal> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> 'Wrote
>> file' | wc -l # 2277 (2nd invocation)
>
> There is NO exif output in that message.

It's IPC, piped to wc. You want me to yank it here? Sure, just
ask man ...

$ repeat 2 for f in **/*.jpg; do exif --remove -o $f $f; done 2>&1 | head -n 10
<f --remove -o $f $f; done 2>&1 | head -n 10
Wrote file 'berlin.jpg'.
Corrupt data
The data provided does not follow the specification.
ExifLoader: The data supplied does not seem to contain EXIF data.
Wrote file 'bike/25-balls.jpg'.
Wrote file 'bike/bike-swamp/adv/vasteras/adv-gear.jpg'.
Wrote file 'bike/bike-swamp/moas-valve/moas-valves.jpg'.
Wrote file 'bike/bike-swamp/moas-valve/valves-2.jpg'.
Wrote file 'bike/bike-swamp/pigeon/front.jpg'.
Wrote file 'bike/bike-swamp/pigeon/hermes.jpg'.
Wrote file 'berlin.jpg'.
Corrupt data
The data provided does not follow the specification.
ExifLoader: The data supplied does not seem to contain EXIF data.
Wrote file 'bike/25-balls.jpg'.
Wrote file 'bike/bike-swamp/adv/vasteras/adv-gear.jpg'.
Wrote file 'bike/bike-swamp/moas-valve/moas-valves.jpg'.
Wrote file 'bike/bike-swamp/moas-valve/valves-2.jpg'.
Wrote file 'bike/bike-swamp/pigeon/front.jpg'.
Wrote file 'bike/bike-swamp/pigeon/hermes.jpg'.

> The only "output" there is from wc -l, and it's you typing
> it as a comment after the shell command, not even showing
> it properly.

Okay, is that in a RFC or somewhere in the POSIX specification?

> The entire thread was a result of your assumption that exif
> would NOT write the words "Wrote file" if the input file had
> no exif tag in it. This turned out to be false. exif writes
> those words every time.

IMO it shouldn't write anything if nothing happens and in
particular it shouldn't take time, which it does. Every time.

> Problem solved.

OK, how should it be done? No computing the second time the
metadata is removed? You do the triangular dance with
filenames, i.e. the tool can't do that? Is that what you mean?

[debia...@howorth.org.uk]

> In programming the focus is perhaps better, for something
> idempotent, something like: Do it the first time. Don't screw
> it up the second time? And don't do the computing if it
> doesn't need to be done?

Sorry, but idempotence says nothing at all about computational
efficiency or cost.

And none of this has anything to do with exif and its behaviour, let
alone its manpage. So please stop trolling.

[Emanuel Berg]

debian-user wrote:

>> In programming the focus is perhaps better, for something
>> idempotent, something like: Do it the first time.
>> Don't screw it up the second time? And don't do the
>> computing if it doesn't need to be done?
>
> Sorry, but idempotence says nothing at all about
> computational efficiency or cost.

Something that has a formal definition can be - and is more
often than not - used in an informal way. That said, if this
is an example of that, I have to say it's _very_ close to the
formal definition.

> And none of this has anything to do with exif and its
> behaviour, let alone its manpage. So please stop trolling.

`1-'

[David Wright]

Well——yes—I thought most people were interested in the output of
$ exif foo.jpg much more than whether there are 2277 lines from
$ exif --remove … … being executed on some collection of files;
IOW what's being done to the EXIF in their images.

> > The only "output" there is from wc -l, and it's you typing
> > it as a comment after the shell command, not even showing
> > it properly.
>
> Okay, is that in a RFC or somewhere in the POSIX specification?

What? exhorting users to paste their commands' stdout rather than
transcribing it into a comment?

> > The entire thread was a result of your assumption that exif
> > would NOT write the words "Wrote file" if the input file had
> > no exif tag in it. This turned out to be false. exif writes
> > those words every time.
>
> IMO it shouldn't write anything if nothing happens and in
> particular it shouldn't take time, which it does. Every time.

I won't ask why you feel the need to keep running with --remove
over and over.

> OK, how should it be done? No computing the second time the
> metadata is removed?

Why oh why "second time"? It's not as if you're removing
individual tags in turn, and using the intermediate versions
of the images for some purpose. I just don't understand the
point of this exercise.

> You do the triangular dance with
> filenames, i.e. the tool can't do that? Is that what you mean?

Cheers,
David.

[The Wanderer]

My guess is: there's a collection of image files which (occasionally?)
gets added to, he wants to clean up this data from the files in that
collection that have it, and he doesn't want to have to keep track of
which ones have and have not already been cleaned up in this way.

(Note: The rest is all speculative extrapolation from that starting
point, and does not necessarily reflect what he actually thinks,
*especially* if that starting point is not valid.)

Thus, he wants to run with '--remove' on every file unconditionally, and
have that Do The Right Thing (including not writing out the file when
there's no need to do so) in every case.

Since exif doesn't have that behavior, the answer is probably to do the
detection separately from the remove command; I imagine there's probably
a way to make exif tell you whether a given file has that data or not,
and you could then use that output as input to an if statement to decide
whether or not to run with '--remove'.

But he seems to feel that it's unreasonable to need to do that, because
it would involve having to run each file that *does* need it through
exif twice in a row rather than just once, and in principle it would be
possible for exif to do the detection internally and avoid the need for
this external logic.

[Greg Wooledge]

On Mon, Sep 26, 2022 at 07:27:45PM -0400, The Wanderer wrote:
> My guess is: there's a collection of image files which (occasionally?)
> gets added to, he wants to clean up this data from the files in that
> collection that have it, and he doesn't want to have to keep track of
> which ones have and have not already been cleaned up in this way.
>
> (Note: The rest is all speculative extrapolation from that starting
> point, and does not necessarily reflect what he actually thinks,
> *especially* if that starting point is not valid.)
>
> Thus, he wants to run with '--remove' on every file unconditionally, and
> have that Do The Right Thing (including not writing out the file when
> there's no need to do so) in every case.
>
> Since exif doesn't have that behavior, the answer is probably to do the
> detection separately from the remove command; I imagine there's probably
> a way to make exif tell you whether a given file has that data or not,
> and you could then use that output as input to an if statement to decide
> whether or not to run with '--remove'.
>
> But he seems to feel that it's unreasonable to need to do that, because
> it would involve having to run each file that *does* need it through
> exif twice in a row rather than just once, and in principle it would be
> possible for exif to do the detection internally and avoid the need for
> this external logic.

Yeah, that matches my guess as well. It's sad, isn't it, that the OP will
spend hours writing pedantic nonsense about the meaning of "idempotent"
or rants about how Debian maintainers should spend their time stripping
historical author identifications out of man pages, but won't spend five
minutes clearly writing out their goals.

Very early in the thread, I made the guess that "exif -o file1 file1"
would act like "sed -i ... file1", in the sense that it *always* writes
out a new file, even if no changes were made. That guess turned out to
be correct.

The basic tools that are available in the free software universe are not
designed to handle *every* conceivable workflow. They're meant to be
used in a specific set of ways, as envisioned by their author(s). Any
additional uses that you can come up with for the tools are a bonus.

Tools that see a great deal of use get additional features added to them,
as the users, maintainers and even the original authors find new ways
to use them.

exif is NOT a tool that sees a lot of use. Not compared to sed, grep,
and so on. Expecting it to do things that *even sed doesn't do* is
kind of unreasonable.

[John Hasler]

rhkramer writes:
> Some examples from (simple) math include adding zero or multiplying by
> 1.

Those are respectively the additive and multiplicative identities. They
are, of course, idempotent but not good examples because they never
change the operand even on first application.

A better example of an idempotent operator is the absolute value
operator.

> An example from "real life" could be pressing the on (or off) button
> on some electronic device.

That's a good one.
--
John Hasler
jo...@sugarbit.com
Elmwood, WI USA