request for a pinned post detailing examples

[simonmcnair]

I think it's quite clear that there is a massive amount of time and effort wasted repeating questions in a slightly different phrased way as well as semantic differences between windows and Linux.

I would request a pinned post of example usage where people put their frequently used command lines and then a mod can test that is works, add it to the main post and delete the response (I don't know if that is possible or not)

This could dovetail beautifully in to https://exiftool.org/examples.html too.

My suggestion would be to have two bold and underlined headings of Linux, windows and regex examples, and then put the examples underneath.

It would also help when Phil or stargeek help someone to do a simple copy and past of the final command with a brief explanation.

I understand it would be an effort, I'm happy to help mod it if it would help and be desired (I run Linux and Windows)

I think this would be a great help, especially with regex's etc.

Sorry if this has been discussed and dismissed elsewhere, or if it is a redundant or useless idea.  I just keep trawling back to my google keep of notes and keep rewriting them for linux, then windows, then troubleshoot the semantics and thought it may help everyone.

[simonmcnair]

example response would be (hopefully correct, not an expert):

Linux

- Recursively add a tag to the tag fields read by Windows. dedupe, maintain data/timestamp, don't backup, show progress bar.
Note(s)
:EXIF:Keywords and XMP:Subject are strings, not lists.
:Windows string tags should be seperated with a semicolon
: the bash command uses a backslash to escape the dollar sign

Code Select Expand

STR="Tag to add to tags that windows reads"
exiftool -api nodups -overwrite_original -P -r -progress:%30b "-EXIF:XPKeywords<\${EXIF:XPKeywords};$STR" "-XMP:Subject<\${XMP:Subject};$STR" -XMP:TagsList+="$STR"  -IPTC:Keywords+="$STR" -XMP:LastKeywordIPTC+="$STR" -XMP:LastKeywordXMP+="$STR" '/this/is/the/folder/to/process'


[Phil Harvey]

While this seems like a good idea on the surface, and there have been attempts at this in the past (you found one of them), the bottom line is that there are so many possible uses of ExifTool that this page would quickly become unwieldy, and in the end it is easier/faster/better to just RTFM.

- Phil

[StarGeek]

Additionally, a very significant percentage of the posts are from people who had one specific thing to do, who don't regularly use or even have never used the command line, and will never post again.  One and done posters

Very often these people don't really even know what the exact terminology of what they are trying to do, which severely hampers their ability to "Read the F* Manual", as would be the response on many other "help" sites.

This last point is a major point for me and is why I have absolutely no problem with answer the same question I have answered hundreds of times before. And it's what severely angers me when I see such responses on other helps sites. Too many of the more experienced people on sites like StackExchange pick out a couple of keywords and assume that it's something that has been posted before, even though the OP mention in their question that they tried the other answer and this question is different in minor, yet significant ways. I far too often suffer from this, even on this site.

But, that said, one of my back burner projects is to organize my notes in to my own "StarGeek FAQ", probably on something like GitHub.  Also, I want to work up a template for new posts with the basic information that required to help trouble shoot a problem.  There are too many posts where people say "this doesn't work" without showing us what "this" is, what kind of file, what version of exiftool, etc, requiring responses to get such information. These people are the most likely ones to fall into the one and done category.

[wywh]

IMO exiftool web pages already have quite good boilerplate example commands.

...at work I wrote manuals. I tried to keep them to the point. But either the info was too short to cover all possible scenarios. Or too long to cover all possible scenarios so no one would bother read it.

...so often the users had not yet experienced the bug the system update had caused. I then repeatedly replied to the user complaints "didn't I tell you about this bug and the workaround in my email a few days-weeks ago", and was greeted with a blank stare or smile.

...the user complaints via email and phone were often very ambiguous. When on site it was often readily clear what it was all about. And many times somehow the error vanished with no user intervention with my "magic presence"

That said, I myself often too hastily have asked help for trivial matters that Googling around would have provided many good answers. And often online nerds like me are too smug to properly answer basic newbie questions.

- Matti