> ls -ld ~/.Trash
drwx------+ 2 fred staff 64B Aug 28 15:37 /Users/fred/.Trash/
> ls -al ~/.Trash
total 0
drwx------+ 2 fred staff 64B Aug 28 15:37 ./
drwxr-x---+ 85 fred staff 2.7K Aug 28 11:07 ../
The directory exists and is empty and readable.
Any suggestion from someone how to approach this problem?
I would definitely turn on "Include Errors" since it might explain exactly what the problem is.
I would also do which emptyTrash in the Terminal to ensure you are actually executing the same command.
There are lots of other possible differences (such as any environment variables in the Terminal which will be different to the ones when executing from Keyboard Maestro, the lack of interactivity, and the current directory).
Status 253 is an exit code generated by the shell command (either bash or emptyTrash), and I don't know what that means.
I would definitely turn on "Include Errors" since it might explain exactly what the problem is.
It didn't make a difference. Any reason why this is not the default btw?
I would also do which emptyTrash in the Terminal to ensure you are actually executing the same command.
I can confirm that it is the same command.
There are lots of other possible differences (such as any environment variables in the Terminal which will be different to the ones when executing from Keyboard Maestro, the lack of interactivity, and the current directory).
I did check the environment variables but could not find any striking difference.
Status 253 is an exit code generated by the shell command (either bash or emptyTrash), and I don't know what that means.
The clue in the end was the message Could not read content of directory /Users/fred/.Trash. It turns out that both the engine and the main application needed to have Full Disk Access permission. I can imagine that this was needed for the engine but was a bit surprised that the app needed it as well. I cannot remember removing and/or needing that permission in the past.
I have a final question though. In the initial error situation I did not get the window with feedback unless I disabled "Failure Aborts Macro". Should it be considered a but that the window that showed the error message Could not read content of directory /Users/fred/.Trash did not show up in that situation?
Because many unix commands spit out random diagnostics or progress reports via the “error” channel.
Some system security settings are applicable to the paren application and then apply to all sub applications and processes. Others need to be done on each sub-process. Only Apple really knows which is which.
If the action fails, then there is no output to the action, hence no window (or any other form of output such as setting a variable or whatever). The error is reported in the notification (which will likely be truncated) as well as in the Engine.log.
Again thank you for coming back to me. It al makes sense to me except for the last part:
If the action fails, then there is no output to the action, hence no window (or any other form of output such as setting a variable or whatever). The error is reported in the notification (which will likely be truncated) as well as in the Engine.log.
The executable does give an error message, being: Could not read content of directory /Users/fred/.Trash. Using the default configuration of the action Execute Shell Script I only get the message that the action failed with status 253. There is no further detail in the Engine.log file either.
For me it is not intuitive that I have to disable Failure Aborts Macro, i.e. ignoring the failure to get to the error message. If this was logged in Engine.log that would have been fine.
An alternative could have been to add an option to log the command output in the Engine.log file or even a user defined log file.
This action, like many actions, takes inputs, and produces outputs. You control where the inputs come from, and you control where the outputs go to. The outputs might be displayed in a window, or saved to a variable or file or the system clipboard, or whatever.
If an action fails, then it does not do the "produces output" step. So if the action fails, it makes no difference whether the output was going to be displayed in a window or saved to the clipboard - that does not happen. Instead the failure is reported in the log file, and with a notification (if the Notify on Failure is enabled). If the Failure Aborts Macro is enabled, then the macro stops (or possibly if it is within a Try or Catch block, it continues in the Catch section), otherwise the macro continues with the next action. But in neither case is the output sent to whatever the action is configured to send output to, because the action has failed.
In all cases, the failure is reported in the log. In cases where the Notify on Failure is enabled, the failure is posted as a system notification. The Failure Aborts Macro setting does not affect the reporting.
The time the Include Errors will make a difference will be where the command outputs diagnostics messages but the script does not end in failure. Outputting text of the error channel and failing are entirely different processes. For example, a shell script like:
adsadsasd
cat
Will produce a diagnostic output for the failure of the first command, but will succeed (so no failure of the macro and no notification no matter what the settings are) because it ends with the valid cat command.
