Open d180cf opened 8 years ago
The problem is the equals sign in the second arg. Jake is choking there because it's trying to parse that as a opt that sets an env variable (as you saw in your fourth example).
It would be great to have an issue filed on this, although it is pretty edge-casey. There are multiple of workarounds here. Off the top of my head:
jake mytask[abc,def,123]
, and joining them inside your taskjake mytask[abc,def%3D123]
Either of these let you parameterize these values, and don't wreak havoc with the Jake arg-parsing.
@mde I agree this should, at the very least, be two args... but Is there a strong reason why wrapping def=123
in quotes isn't supported? Can you point me to the code that handles that?
Here is the offending line of code: https://github.com/jakejs/jake/blob/master/lib/parseargs.js#L114
I'm sure there are smarter ways to do this.
Yeah, sorry, I should have updated my post to say I already found it. I have a pull request for it (#312), though no tests yet (it was late, I was sleepy) - it basically just checks for a bracket in the first item in the split and if it exists it assumes it's a command (despite it passing the length check).
There may be better/smarter ways, still, but it works.
The big problem I see, however, is that it's technically a breaking change. If anyone has env variables with a [ in it, it will no longer work properly. I'm not sure if there's a way to fix the issue without breaking that behavior.
Let's say I have a task in jake that needs to end up calling
node myscript abc def=123
. I have tried the following:jake mytask[abc def=123]
- here jake dropped everything after the whitespacejake mytask "abc def=123"
- the quoted string was ignored by jakejake mytask[abc,def=123]
- jake seemed to fail the input and just run all the tasksjake mytask args="abc def=123"
- jake assignedabc def
toprocess.env.args
Is this even supported?