Yes – i think this was a recent change put in so that the case where a nsh parameter was blank in the gui would not reduce the number of arguments passed into the script, so that the subsequent args would still map to the correct input in the script.
So if my script takes 3 args and my nsh script params in the gui are like:
This change would prevent arg2 from reading val3.
Thank You Bill,
However could you please let me know if there is any alternate rather than hard-coding the default buffer value \000 in original script?
I am looking a work around where I should be able to put some default value which will be treated as NULL. to satisfy the condition in the scripts.
As the above workaround stated will not be very easy for me to apply as there are so many jobs use the same scenario.
Any Update? or Any Inputs
Bill that change is a rather huge one which could potentially have impacts on many of our scripts. Which version was it changed in exactly? We are currently still using 8.3.03.116, working towards r190 right now.
For example, we often use the argument counter to define if we're missing arguments, i.e. :
if [ $# -ne 4 ]; then
echo "[ERROR] Missing arguments."
If blank arguments now increment the count as if they were enclosed in double-quotes, this means the above would no longer trap this case and the script would still try to run with a blank value. This is rather major, and it goes against every known shell mechanic ! No other Unix shell does this unless the arguments is enclosed in double-quotes. If BSA does this naturally as soon as a parameter value is empty, it's not good, and it should probably be changed to add a checkbox next to each parameter to optionally enclose the value in double-quotes when passing it to the script, which would be having the same effect.
By the way I'm not saying this is necessarily a bad idea, and it would have actually been nice that it had always worked like this from the beginning. However, because of the impact (we will need to update a ton of scripts because of it), this change should be optional per parameter or NSH Script Job (either way), and not default behavior.
8.5.0 i think, maybe 8.5.01…
We had a lot of tickets where users did not like the behavior where if you leave one of the parameters blank it shifts the args down, so if arg3 is blank, arg4 becomes arg3, arg5 becomes arg4. That was also seen as a defect as there was no way to pass a “” which you might do from the command line. i’d have to check what actually gets passed into the shell if you do a “” – maybe we can send that instead of the \000 but \000 should be a null. the snippet you list below is a workaround for the original problem.
I can understand that some users felt it was a defect since you couldn't pass "", but that should have been the actual solution (to make NSH Script Jobs explicitly enclose all arguments in double-quotes even when they are blank). However, doing so this late in the product's life means it has a lot of impact and will not be a transparent change for everyone. That's my biggest concern, the lack of backward compatibility. We'll need to review a lot of scripts to avoid issues following this change.
That's why I think it should be an option per-parameter. For example, just add a checkbox such as "Always enclose in quotes" in the parameter edit dialog, and make it so that when checked, it encloses the value in double-quotes (even when blank), and when not, it does like it did before. That would be IMO, the best way to avoid impact, and I don't expect it to be a hard change to do either even if it requires a bit more programming than simply changing the default for all parameters.
I do agree this is not what should happen… can you open a ticket for this and let me know the number ?
Did you mean to reply to Pravin? I can't really open a ticket for a version I'm not yet using (we're still at 8.3), our PSE wouldn't like that lol !
Yeah – for Pravin or whoever started the thread. i just replied to the email..
It was changed in 8.5.00 it looks like (QM001804730). I created a new defect for this - QM001871503.
Thank you Bill !
In the meantime until this is fixed, this is what you can do to handle those values:
Let's say you have 10 optional parameters in your script, starting at the 5th position... You can use the built-in regex replace substitution of zsh to set the params to an actual null value like so: