Option to place user software before generated code placement.

[TranslucentSabre]

I have a script that I have converted from getopt to argbash, and in doing so I seem to have hit some limitations.

I would like to be able to run some user code before the generated code runs, specifically the declaration of the default argument/option values.
I would also like to be able to use help more dynamically, with default values listed in variables. This help use-case I've been able to work around by using ARGBASH_PREPARE and calling the generated API from my own code, but I am concerned about updating to a new major rev and the new generated API being different in the future.
I will see if I can update my script as an example. If not I'll paste in some snippets.

[TranslucentSabre]

remind.txt

Please note that while the script does manage to display my default values properly in help I have to treat them as if their defaults are blank because the variables they should be using haven't been declared at the time they are declared.

It would be a little bit better if the defaults were set in a function which was called in the generated API, either standalone or at the beginning of the parse function. This function could then be used in my existing workaround to perform the initialization of the defaults after my prerequisite code had run.
This would not, however, fix my concern about the API changing out from underneath me.

[matejak]

Hello, you can place your code before Argbash macros, but at the moment, it may cause problems if you use square brackets in it.
I also see that the generated shell function API could be documented better, and given a second thought, they could have been declared stable. You don't have to worry about big changes to API, backwards compatibility is a huge deal.

[TranslucentSabre]

Thank you for your response. I see that it does remain after further testing, and after reading https://argbash.readthedocs.io/en/latest/usage.html#template-layout again I see where is does mention user code in part 1 of the template. I would just need to manually wrap the block in [ ]s each time I needed to run argbash if I used square brackets, correct?

Would you be open to a possible pull request to initialize default values in a new function call which is called in the generated code? I can still see some, admittedly corner case, use for that.

[TranslucentSabre]

I am ignorant of m4, but on second thought, if I wrapped my code in part 1 in a manual invocation of m4_ignore([ ]) would argbash processing of it leave that whole section, m4_ignore call and all, untouched? I'll try this in a bit as well.

[TranslucentSabre]

Ok, so if I do wrap my code before the template in m4_ignore it is eaten when being run through argbash.

[matejak]

It is important to clearly define the use case first, as there may be more ways how to make it work. AFAIK, you are referring to this:

You would like to run some code before processing of the command-line. This is required if you would like to have dynamic values of defaults or another arguments to Argbash macros.

Concerning your idea to make defaults initialization a function, feel free to propose a patch, it is a 80% bash and 20% of m4, so should be relatively easy. I am a fan of a more clearly defined layout of the generated code. However, I understand this to be relevant only in the ARGBASH_PREPARE mode, as ARGBASH_GO is supposed to work out-of-the box, batteries fully plugged in.

[matejak]

I am not thinking of an ARGBASH_PRESERVE macro with multi-line input. That macro would just output its call, so it would remain there even when argbash is rerun.