alias with arguments does not take additional arguments into consideration

[maxandersen]

when doing jbang alias add something.java -S , i.e. have the alias seeded with some arguments then doing jbang something works, but jbang something additionalarg fails.

we are somehow ignoring/combining arguments in a non-working fashion when using aliases.

[maxandersen]

the concrete example I had was an alias like jbang alias add -f . --name serve com.intuit.karate:karate-core:0.9.9.RC2 -S

in this case you should be able to do jbang serve -p 8000 and see it start on another port.

But it doesn't - it just runs as if no arguments was passed.

[maxandersen]

@quintesse any idea ?

[quintesse]

@maxandersen yes, that's how I designed it :-)

Which might be wrong of course. But it follows the same idea as //REPOS, there are default arguments/repos, when you manually specify arguments/repos the default ones are overridden.

I actually thought about allowing some kind of syntax/option that says that additional arguments should be added instead of overriding the default ones but it's not something that's currently implemented.

[maxandersen]

Well its broken no matter what as the Alias call without argument works but with argument it fails :)

I think the usecase above is a great usecase where Aliases should allow appending of arguments.

[quintesse]

Ah so if you run jbang serve com.intuit.karate:karate-core:0.9.9.RC2 -S it doesn't work?

[maxandersen]

Here is the issue:

jbang alias add -f . --name run com.intuit.karate:karate-core:0.9.9.RC2 -S

now, jbang run works and runs karate with -S

but doing jbang run -p 8000 it runs as if only -p 8080 have been passed.

afaik both alias in bash/zsh/git the arguments are part of the alias, so anything additional are simply appended.

[quintesse]

Ok, but that means it does work as I at least intended, it's not broken, you just don't like how it works :-)

[quintesse]

I have no problem with changing it to the way you want btw. I considered both options at the time and just chose one.

[maxandersen]

Ok, but that means it does work as I at least intended, it's not broken, you just don't like how it works :-)

True :) I didn't realise this specific app ignored irrelevant flags:)

[maxandersen]

I have no problem with changing it to the way you want btw. I considered both options at the time and just chose one.

I think appending actually gives value as it means you can simplify and compose.

Where as with replacement you don't really get much help.

[quintesse]

My way of thinking was that in most cases the most difficult thing about an alias is the URL, hard to remember and hard to type. At the same time once you specify arguments there is often no way to "unspecify" them, so overriding them instead of appending them seemed useful. But I admit the choice was a somewhat arbitrary and I have no issue with doing it your way.

[robin-a-meade]

The current behavior surprised me.

I creating an alias named color_sqlline:

jbang alias add 
  --name=color_sqlline \
  --deps com.oracle.database.jdbc:ojdbc8:23.3.0.23.09,com.h2database:h2:2.0.204 \
  sqlline:sqlline:1.12.0 --color=true

jbang color_sqlline ⇐ Will use color jbang color_sqlline --nullValue='***' ⇐ Will NOT use color

I'm used to bash aliases. Consider:

alias ls='ls --color=auto'

ls ⇐ Will use color ls -l ⇐ Will STILL use color

[quintesse]

@maxandersen I've created a PR for this, but it's somewhat of a breaking change of course, so you need to decide if you want this or not :-)

[maxandersen]

@robin-a-meade thanks for reminding us to fix this :)

@quintesse thanks merged! and yes its a breaking change but a good one imo.