Enhance <exec> action with redirection to files

[end2endzone]

Is your feature request related to a problem? Please describe.
The current way to allow redirection of stdout or stderr to a file is by running a shell command through cmd.exe and shell stream redirection.
For example, >output.log or 2>&1.

This is more of a workaround than an actual implementation.
An actual properly implemented feature would be more convenient and prevent many action to rely on cmd.exe shell stream redirection.

Describe the solution you'd like
The <exec> action could be enhanced with the following attribute:

<exec path="cmd.exe" wait="true" arguments="/k &quot;ffmpeg -version&quot;"
  stdout="${selection.path}.output.log"
  stderr="${selection.path}.err.log"/>

and to redirect stderr to stdout, you could do:

<exec path="cmd.exe" wait="true" arguments="/k &quot;ffmpeg -version&quot;"
  stdout="${selection.path}.output.log"
  stderr="2>&amp;1"/>

Describe alternatives you've considered
N/A

Additional context
N/A

[end2endzone]

Consider also the following enhancements:

<!-- redirect to files -->
<exec path="cmd.exe" wait="true" arguments="/k &quot;ffmpeg -version&quot;"
  stdout-file="${selection.path}.output.log"
  stderr-file="${selection.path}.err.log"/>

<!-- redirect to properties -->
<exec path="cmd.exe" wait="true" arguments="/k &quot;ffmpeg -version&quot;"
  stdout-property="myapp.output.log"
  stderr-property="myapp.error.log"/>

Also define stdin-file and stdin-property properties.
This would allow doing sequential exec action which redirect one into the other such as the following:

<!-- get full output of ipconfig -->
<exec path="cmd.exe" wait="true" arguments="ipconfig"
  stdout-property="ipconfig.output.log"/>

<!-- filter for lines that contains IPv4 string -->
<exec path="cmd.exe" wait="true" arguments="findstr IPv4"
  stdin-property="ipconfig.output.log"
  stdout-property="my.ip"/>

<property name="ipconfig.output.log" />

[Aptronymist]

I think this would be a good feature to add, however I'd take it a step or two further and also allow output to a custom log window/dialog box using some of the existing ui functionality.

[end2endzone]

Thank you for showing interest in this. Reading your comment, I am uncertain about what you mean. I will probably not have time right now to implement this in the next months so I would like to take this opportunity to get more information about your feedback. Could you explain what you would be expecting with such an enhancement ?

allow output to a custom log window/dialog box

If you would like to have the output to another window, could you just have cmd.exe call you target executable and cmd.exe will create a window that wraps your executable's stdout ?

If you were actually thinking about creating a ui window that would be handled by ShellAnything, I do not think I would go this route. Mostly because because ShellAnything is a shell extension and the nature of a Shell Extension is usually to only have momentary control of the execution flow. For example (it might be a design flaw), Prompt Windows/Dialog that are displayed with the Prompt Action were implemented as pure sequential calls to be easily integrated into a Shell Extension (a.k.a without threads, without a messaging loop, without semaphores to protect concurrent access). When a Prompt is displayed, it blocks the flow of execution of File Explorer until you press Cancel or OK. In another words, the user can not right-click on another file or do another file action until you press Cancel or OK.

To show a Window, I would need to create another thread that would run a messaging loop. That is, change the design from "momentary execution" to a design where there is something that "always run". I would also have to deal with semaphores (mutex/locks) to protect against concurrent access. File Explorer continuously ask a Shell Extension if it can be "unloaded" (see specific API called DllCanUnloadNow()). If I would have another thread, I would have to make sure ShellAnything's ressources (windows, processes) can be freed as well.

If I would need to wrap an executable's stdout into a window, I would create an independent executable for doing this specific feature. But then again, cmd.exe is doing exactly this.

[...] using some of the existing ui functionality.

This is where I am more confused. ShellAnything has not much ui functionality. It can show menus and it can create prompts to get
user feedback. What do you mean by the following statement ? What I think you means by that is the following:

Scenario A: Having a custom log file

1. User right click on an executable.
2. ShellAnything display a menu called "Run and log output to custom file".
3. When selected, a Prompt is displayed asking what the custom output log file name and location should be.
4. ShellAnything runs the executable and uses stdout-file="${prompted-file-path}" to write the stdout to the custom file.

or

Scenario B: Having multiple reusable output windows for logging

1. User right click on an executable.
2. ShellAnything display a menu called "Run and log output to file >" (notice the > expanding menu).
3. User select the menu.
4. ShellAnything shows 4 menu items named Log window 1, Log window 2, Log window 3, Log window 4.
5. When user selects log window 3, ShellAnything runs the executable, showing the executable's stdout in the third Window

Did I understood correctly what you meant ?