casey
Running multiple receipts with default arguments
When invoking multiple receipts (which is not a documented feature in the Readme), the commands and arguments are ambiguous. Given this justfile:
backup file="default":
@echo backup {{file}}
exit 0
restore file="default":
@echo restore {{file}}
exit 0
test:
@echo testing
exit 0
The following behavior can be observed:
$ just backup
backup default
exit 0
$ just test backup
testing
exit 0
backup default
exit 0
$ just backup test
backup test
exit 0
I would like the last invocation to call the backup receipt with its default parameter and then (when successful) the testing receipt.
Instead, the second argument is interpreted as the parameter to the backup task. A solution for this inside the justfile is documented in the Readme: https://github.com/casey/just#recipe-parameters
To pass arguments to a dependency, put the dependency in parentheses along with the arguments:
Is there something similar for the invocation via the CLI?
This currently this isn't possible, but I could imagine supporting this somehow, like just ( backup test ), although this is complicated by the fact that ( is a special character, at least on zsh, and ) is a valid recipe argument.
Is the multi invokation of recipes explicitly supported, or does this work by accident?
I would argue that one could always just make a specific recipe that simply calls the other recipes explicitly with the parameters they're supposed to receive.
Invoking multiple recipes is explicitly supported. It's mentioned in the readme, there's an example early on, search just build sloc.
In that case, I think this ambiguity should be solved.
As an alternative to brackets, how about quotation? just "backup" "test" or just "backup file" "test"
Quotes won't work, because they are interpreted by the shell, so just won't see them, and trying to split strings is generally hard. I think using some character to group command line invocations is probably the best bet.
Maybe the docs should just say this is an edge case? It's an inherently hard problem to solve on posix-y shells, and deciding to not support it is a valid choice.
Although maybe it could take properly structured data through nushell or powershell or something :P
Hello, I just wanted to use the same feature and searched for an issue here. Maybe it's possible to use something like this:
just backup: test
that is parsable by just and not useable as a target name? How about that?
just backup: test looks good, as far as syntax goes, but it only works with one argument. If a recipe has multiple arguments, then only the first could be set.
Yes, you are right, this works only for the first parameter. But we could play with the number of colons:
just backup: test #for one argument
just backup:: test #for two arguments
Would that be possible?
Multiple colons seems pretty weird. I think the best choice is [. Bash, zsh, and sh don't treat [ and ] as special as long long as they're alone, so just [ foo 1 2 3 ] [ bar 3 4 5 ] works.
I'm a bit new to Just, but this is something that just caught me out, too!
I think perhaps there's a bit of a precedent with tools like find / fd (et al) escaping ; characters when executing commands.
Perhaps leaning on conventions like this would work?
I imagine there's similar convention(s) in Posh and CMD.exe...
e.g.
just build-and-test FRED JANE MATTHEW \; deploy FRED JANE MATTHEW
I'm a bit new to Just, but this is something that just caught me out, too!
I think perhaps there's a bit of a precedent with tools like find / fd (et al) escaping
;characters when executing commands. Perhaps leaning on conventions like this would work?I imagine there's similar convention(s) in Posh and CMD.exe...
e.g.
just build-and-test FRED JANE MATTHEW \; deploy FRED JANE MATTHEW
And if \; is a bit too niche, perhaps another character would work.
; is annoying because you have to escape it, whereas [ you don't. Also, ; is a valid argument, whereas the opening [ lets us know to treat ] as special, and so if you want to pass ] to a recipe, it won't break on its own.
;is annoying because you have to escape it, whereas[you don't. Also,;is a valid argument, whereas the opening[lets us know to treat]as special, and so if you want to pass]to a recipe, it won't break on its own.
Heh, I think we were replying in-parallel.
Yup — it's def. niche unless you've been fighting with bash for a few years ;-)
Kind-of thought :: "felt good" as an alternative, except that : is sometimes a bit special in Windows, IIRC.
;is annoying because you have to escape it, whereas[you don't. Also,;is a valid argument, whereas the opening[lets us know to treat]as special, and so if you want to pass]to a recipe, it won't break on its own.Heh, I think we were replying in-parallel.
Yup — it's def. niche unless you've been fighting with bash for a few years ;-) Kind-of thought
::"felt good" as an alternative, except that:is sometimes a bit special in Windows, IIRC.
Actually, have just remembered that ; is often used as a separator in Windows, e.g. in the PATH en-var.
So if you go down this route, perhaps a couple of interchangeable options, to allow for OS differences and/or experiences.
I'd normally agree that one single+clear version is good, mind you...
Multiple colons seems pretty weird. I think the best choice is
[. Bash, zsh, and sh don't treat[and]as special as long long as they're alone, sojust [ foo 1 2 3 ] [ bar 3 4 5 ]works.
The [ foo 1 2 3 ] version also looks very nice
Tried this sometimes (and failed) found this issue, read through it and … honestly? IMO you should just drop support for this. It's an edge case, easily solvable by concatenating multiple just commands with && or ;.
@nem75 that's not equivalent. If recipe A and recipe B both depend on recipe C, just A B will run C once. just A && just C will run C twice.
