Use of -q when in stay_open supresses {ready}

[TSM]

Not sure if to clasify this a bug, if you use -q to have quiet output when using stay_open suppresses the {ready} flag to indicate the end of the data output which seems odd as otherwise you would not know if you have received all the data.

[Phil Harvey]

This is by design, and is a potentially useful feature that gives you the maximum flexibility.  If you really want to use -q for other reasons, you can generate the "{ready}" manually with -echo3 "{ready}".

- Phil

[Andi]

From the documentation:

Arguments in ARGFILE behave exactly the same as if they were entered at the location of the -@ option on the command line, with the exception that the -config and -common_args options may not be used in an ARGFILE.

You should add -quiet here as well because I cannot relate outputs any more to their commands when executing several at once. I consider this program behavior a bug although it is not by mistake, because the ready messages exist for a logistical reason: to be able to relate input to output. You would never output them after processing.

The same problem exists for error output where I miss ready messages even without -quiet option. I try to solve this problem in the following way:

As first option I add an unknown tag followed by white space, for example '-Token123 ' which leads to a bunch of lines with error message Invalid TAG name: "Token123 ". This way I can relate all the following lines up to the next token message to a command.

[Phil Harvey]

How about this?:  I could change it so the "{ready###}" message is output even if -q option is used, but only if a "###" is provided.  (ie. "-q -execute" would not produce a "{ready}" message, but "-q -execute123" would produce "{ready123}".)

- Phil

[Andi]

How about this?:  I could change it so the "{ready###}" message is output even if -q option is used, but only if a "###" is provided.  (ie. "-q -execute" would not produce a "{ready}" message, but "-q -execute123" would produce "{ready123}".)

- Phil

This sounds like a good idea but how can I make sure that a large result is ready? Some EOF code is needed anyway, so it is better to keep the ready messages or to find a better and clearer solution.

To put it into perspective, I would propose the following solution:

- Keep the ready message and keep it in stdout as the last output. It must always be after any other stdout and stderr output for each command. This way I know if the result is ready.
- Add an option to include the same message to the stderr stream. If requested, it will be appended to the error stream for each command (like with stdout no matter if there were errors or not), and it should come before the stdout message. This should only be used when streams are redirected separately, so that parsing stdout and stderr can use the same algorithm. If streams are combined, the stdout message is sufficient.
- I want to know the exit code (because if stderr has output, this does not always imply exit code != 0), so it can be included into the ready message by option as well.
- The only non-backwards compatible API change I would recommend is: To simplify parsing, treat the "ready" keyword as the default token. If the user provides his own, use it instead of "ready". Examples:
{ready0} or {owntoken0}, error exit: {ready1} or {owntoken2}.

You have more insight into the API, but I guess somehow these features should be implemented in a way they can be used together with the normal -execute command without -stay_open as well?

[Phil Harvey]

- Keep the ready message and keep it in stdout as the last output. It must always be after any other stdout and stderr output for each command. This way I know if the result is ready.

This should be the way it is now.

- Add an option to include the same message to the stderr stream. If requested, it will be appended to the error stream for each command (like with stdout no matter if there were errors or not), and it should come before the stdout message. This should only be used when streams are redirected separately, so that parsing stdout and stderr can use the same algorithm. If streams are combined, the stdout message is sufficient.

You can do this now using the -echo4 option.

- I want to know the exit code (because if stderr has output, this does not always imply exit code != 0), so it can be included into the ready message by option as well.

I'll have to think about this, but I could in theory add this as a feature in -echo3 and -echo4.

- The only non-backwards compatible API change I would recommend is: To simplify parsing, treat the "ready" keyword as the default token. If the user provides his own, use it instead of "ready". Examples:
{ready0} or {owntoken0}, error exit: {ready1} or {owntoken2}.

You can do this too with -echo3 and -echo4.

- Phil

P.S.  One other minor point:  This is not what I call the API.  These are features of the command-line interface.  What I call the API are the routines used by Perl programs to interface with the Image::ExifTool library module.

Edit: I'm testing a feature that allows the exit status to be inserted in the -echo3 and -echo4 output by using "${status}" in the text string.

[Andi]

This should be the way it is now.

Correct.

You can do this now using the -echo4 option.

I didn't have that in mind. This does it!

- I want to know the exit code (because if stderr has output, this does not always imply exit code != 0), so it can be included into the ready message by option as well.

I'll have to think about this, but I could in theory add this as a feature in -echo3 and -echo4.

...

Edit: I'm testing a feature that allows the exit status to be inserted in the -echo3 and -echo4 output by using "${status}" in the text string.

This way, -stay_open would be perfect.

P.S.  One other minor point:  This is not what I call the API.  These are features of the command-line interface.  What I call the API are the routines used by Perl programs to interface with the Image::ExifTool library module.

I used sloppy terms. Thanks for making this clear.
BTW: Perl (5?) was the first programming language I ever learnt. I teached it myself long ago to program websites, ~ 2002.