Not sure I would feel secure pushing dynamically generated JSON directly as an argument to a Clojure function on the command line. I would be much happier if the command pushed JSON to a file and then that filename passed as an argument to the Clojure function. As well as being simpler, it would also keep a separate record of what JSON was passed to the function. Or at least pass the generated JSON through a tool to convert to EDN safely and then pass as an argument. Adding an escape character / for certain argument values feels a bit cryptic in terms of usability, but admittedly I don't have any use cases that would take this approach anyway.

It's not just about JSON, it's about having to quote arguments if you just want the vanilla cmd line string in general. A workaround is to parse symbols and then convert them to strings again, but this can result in invalid symbol reads. Quoting in shells is just hard and also makes it a bit more verbose. Having a way to bypass this is imo useful. Having a less cryptic way: all for it! I'm curious about other alternatives :).

hmm… You can always use *command-line-args* but you’d probably want to switch from -X to -M for invocation in order to stop that parsing altogether. For the JSON case you’d almost certainly be better passing it via stdin or a file though. Regarding the separator / it also strikes me as confusing because it’s the unix path separator and iirc it used to be a /arg separator in DOS — not used Windows for over 20 years though, so no idea if that’s still relevant 😆

Introducing a special escape character to simplify escaping rules also feels like a bit of a contradiction

@borkdude: Also one question; in your JSON usecase how would such a thing know to escape strings in the JSON from both the clojure reader and the shell?

I definitely get the motivation for such a thing, I’m just not sure there’s going to be a good solution :thinking_face:

@rickmoynihan I know command-line-args and -M, that's what I've been recommending when people run into this, but some of the tooling went the -X route and even deprecated -M usage, so you will run into this no matter what.

yeah though arguably that’s a problem for the tools… I mean they should pick the flag/approach for the job.

for me, the open question is whether this is something that should be annotated on the function or at the CLI

I think the problem is that affordances of -X and build.clj are too good 🙂

well, that's the first question :)

When I try to download all version of com.google.javascript/closure-compiler-unshaded t.d.a returns nil, digging in the problem I saw that this https://github.com/clojure/tools.deps.alpha/blob/master/src/main/clojure/clojure/tools/deps/alpha/extensions/maven.clj#L190 is being responsible to the problem since it’s only matching versions starting with number and all the versions of com.google.javascript/closure-compiler-unshaded starts with a letter v. Is it supposed to work like that or is it a bug?

Maven version components are (usually) numbers

Can you back up to what you're actually calling?