Bug: Strange Behaviour of Arguments in Shell Script Node

Hi!

as a workaround for a missing aspect ratio in the Crop node (see Feature Request: Custom Aspect Ratio in Crop Node) I tried to write a shell script and do the crop with imagemagick.
The arguments behaviour is not clear to me. When I pass no arguments to the shell script the path to the image (loaded with the “Read Individual Files” node) is in $1
When I pass arguments, for example a b c then in $1 is a, in $2 is b, and in $3 is c. The path to the image is not available anymore.

Thanks and regards
Alex

That’s a problem.

So, can see two ways to fix this, without breaking anyone’s existing workflows (hopefully).

  1. Just append the image path argument to the end of the list. This way it won’t change the order of any existing arguments
  2. Add a new “ImagePath” variable which can go in that field, and future nodes will insert it as a default.

Personally, I’m for option 1. But I’d like to hear feedback on these if you have any, or maybe other ideas.

-gus

Hi Gus,

thanks for the fast reply.

My thougts about your suggestions:

Suggestion 1: This means that the current behaviour remains to avoid breaking changes in existing workflows. And there are 2 use cases.
Use case 1: I have several arguments in the “Arguments” field of the UI. e.g. a b c
Technically this means I have the following vars and values:
$0: path to the shell script
$1: a
$2: b
$3: c
$4: path to the image

$4 is automatically appended by retrobatch depending on the number of arguments

Use case 2: I have no arguments in the “Arguments” field of the UI.
Technically this means I have the following vars and values:
$0: path to the shell script
$1: path to the image (current behaviour)
$2: path to the image (new automatically appended by retrobatch)

Suggestion 2:
Is for me the only slightly different to suggestion 1 but with the main difference that the user will see the ‘imagePath’ argument in the “Arguments” field.
Depending on what the user is doing in the “Arguments” field it needs some more handling magic in the background with the variables.
AND the most important: a clear documentation about this feature is necessary for the user!

I think #1 is the better worse way. But in the end it is not really consistent. And every new feature in the shell script node might build up on this workaround.

What about introducing a new shell script node? Shell Script Node NG (next generation). which implements the arguments correctly. You have no breaking changes in existing workflows. Transparent and clear documentation will help the new users to use the correct node. And users with existing nodes can migrate. After some time the v1 script node is ready for deprecation?

I hope my thoughts help a little bit…

Regards
Alex

RB would only append the path if there were no arguments. If there was $ImagePath$ as a single argument, then only $0 and $1 would be passed. And it’s only added as a default value for new instances of the shell node. Existing nodes would keep the same arguments.

The main problem with the $ImagePath$ variable, is that it doesn’t make sense for the preflight and postflight actions.

Adding a new shell node isn’t something I want to do. I’ll just have to call out the changes in the release notes and documentation.