Summary: I've noticed a strange behaviour (in WFA 4.0 and 4.1) when writing a Perl commandlet. Although I define the parameters correctly (I think), they are not passed to the perl code properly unless I actually craft a Powershell param() equivalent and use that to discover the parameters.
Take this simple example:
my $wfa_util = WFAUtil->new();
my $success = 'true';
"success:s" => \$success
) or die 'Illegal command parameters\n';
$wfa_util->sendLog('INFO', 'Success: ' . $success);
I define a parameter "success" as a boolean on the "Parameters Definition" tab and the "Parameters Mapping" tab is populated automatically. Now when I run this commandlet, I always get "Success: true" despite what value I select on the test. Diving into the perl specifics, it looks like the parameter is passed only after a '--' argument which causes GetOptions to ignore the parameter.
The only way to get aroud this seems to be to define a minimal PowerShell script which can be used to discover the same parameter (i.e. the config tabs look exactly the same as before after the discovery):
Thanks for looking into this. And I've found the problem as well. Why not write your first ever post based on a rookie mistake, kinda makes sense ...
I was about to recreate the commad one more time in order to export to dar as you requested. This is when I finally realized my mistake. When adding the parameters manually, you press "Add Parameter" to add a blank line. I then double (!) clicked the name column of that blank line to fill it in -- not realizing that a double click will put the cursor behind a single space character. So I ended up adding a parameter called " success" rather than "success" everytime which obviously cannot work.
Apologies for the rookie mistake, but at least posting here helped me solve my personal problem. Yay for the community.
Maybe there are technical reasons for putting in the single space character for new parameters - if not, it might make sense to remove it in future versions to avoid my mistake?