How to use optional arguments in main()

Paragon

Member
I was wondering if anyone knew if there was a way to have an ash script that had a main function that would take optional arguments.
I.E
void main (string arg1)
{
}

where calling the script with no arg would not pop up an input box. Can I overload the main function?

void main (string arg1)
{
}
void main ()
{
main("");
}
I should try that.... hm... anyway, If anyone has any definite answer or a link to a post talking about this sort of thing I would really appreciate it.
 

Leperconartist

New member
First off why do you want the option to give it a value? How does this help anything? If there is no way perhaps we can find a way around it.

And Second Off has anybody figured this out yet?
 
Plain and simple: no.
You can't overload main.

You can give it arguments if you want, but they are all mandatory. If you give it more than one argument, then you can't invoke it from the gCLI (easily, at any rate) but you can from the scripts menu.

Not sure why you'd need it to be optional anyway... don't want to supply a string, give it an empty one. (not sure the gCLI allows this, but if not you can just give a dummy string.)
 

fronobulax

Developer
Staff member
I can't find it posted, but Bale rewrote the main for EatDrink so that the argument was a string and then he parsed it to see what had been the individual arguments.
 

StDoodle

Minion
As soon as you pass a string to a script on the cli, everything else is treated as part of said string*. The up side of this is that you can simply accept a single string as an argument, then run split_string() on it to get your "multiple" arguments. Since you can choose the delimiter(s) for split_string(), you can have any format you want (useful if some arguments might need to contain spaces).

* Gross oversimplification, perhaps. Sorta.
 

stannius

Member
Not sure why you'd need it to be optional anyway... don't want to supply a string, give it an empty one. (not sure the gCLI allows this, but if not you can just give a dummy string.)

For scripts that use adventures, it would be nice for there to be some way for the user to give a max # of adventures to use, but not have to give anything if they don't want, in which case it would use all adventures.

I don't mind parsing a string, but from my experimentation, if there's a string argument, you have to pass something. Even a few spaces after the command doesn't count. Not sure what would happen if you passed "" - would it end up with an empty string, or with "\"\""? - but that's awkward for a user to type so I guess just an interesting detail.

The precedent when you use the CLI adv[enture] command is that it assumes if no argument. That the opposite of what I wrote above, and probably not an default that most people who run an adventure-burning script would expect. So if one were to do this in an adventure-burning script, one might use a required string argument, and allow standard stuff like "*" and "-10".
 
Last edited:

StDoodle

Minion
I don't mind parsing a string, but from my experimentation, if there's a string argument, you have to pass something. Even a few spaces after the command doesn't count. Not sure what would happen if you passed "" - would it end up with an empty string, or with "\"\""? - but that's awkward for a user to type so I guess just an interesting detail.

Well, passing "" will work (and it appears the cli escapes them for you, but I could be confusing what happens when), but you're right that you need to pass something other than whitespace to avoid the prompt. The best solution I've found is to just set an alias and use that. Ie for my old "customdaily.ash" script, which parsed a string for arguments, I set the alias "cdaily => customdaily.ash -%%" so it just passed an extra dash in front of anything else. The dash was enough to avoid the prompt and was ignored in the script (treated as no arguments). Then instead of invoking the script on the command line, I just typed "cdaily" with or without arguments. As a bonus, I could call the script without the alias to have access to the "regular" behavior as well.
 

stannius

Member
The best solution I've found is to just set an alias and use that. Ie for my old "customdaily.ash" script, which parsed a string for arguments, I set the alias "cdaily => customdaily.ash -%%" so it just passed an extra dash in front of anything else.

Considering the consumers of a hypothetical script, most of them won't know how to set an alias. Is there a way to do it automatically? I suppose a simple
Code:
cli_execute("alias scriptname => scriptname.ash -%%");
would work, at least after they "suffered" the prompt once the first time they run it.
 

Winterbay

Active member
You could look at BCCascend which in its most recent form registers quite a lot of aliases for different things if you want to see one way it can be done.
 

slyz

Developer
Paragon had posted a script called EZStartInfo which allowed scripts to be called a lot more flexibly.

Unfortunately, I just had a look at the thread and it seems he removed his code. I'll have a look on my computer when I get home to see if I still have it lying around.
 
Top