I'm not sure how useful this would be since we also have tasks

Seems like a nice addition to me. I generally prefer to wait until I have a specific use case before adding new stuff. I find it easier to judge whether it's a good solution then.

Yep

I'll probably wait with adding babashka.cli as a built-in until the nnext version

Hmm, actually the nbb -x ... idea makes sense for nbb since it hasn't got a task runner and it's a cheap way to make CLIs

We use a static binary build of cljstyle

@U03J48P76RW cljfmt also has a binary. but clojure-lsp can also be used as a binary CLI

clojure-lsp just uses cljfmt I think. cljstyle is derived from cljfmt if I'm not mistaking

Yes, cljstyle is based on cljfmt. I didn't know that clojure-lsp binary can be used for code formatting though

Hmm I didn't think of using an lsp - they don't always work with kakoune (my editor), but I'll try that first, before the binaries you mention, thanks both

It took me some time to realise that clojure-lsp works with my scripts, iff they have the .clj extension! Formatting works great, thanks again

@U03J48P76RW Doesn't it also just work when you enable clojure-mode?

What's clojure-mode? An emacs thing? My editor is kakoune, I have a filetype but it doesn't seem transmitted to lsp.

cc @UKFSJSM38

Never tried kakoune, but if it supports LSP it should work with clojure-lsp, LMK if need any help to setup the integration, we can also add a note on https://clojure-lsp.io/clients/

@UKFSJSM38 Does lsp depend on a .clj extension or does it work in emacs when you set clojure-mode regardless of the extension? (I know flycheck-clj-kondo does work regardless of extension)

@U04V15CAJ it should not depend, but not sure if it works ATM, if not we should try to fix it

But it could have a performance impact if it has to inspect tons of non ".clj" files in the directory

No, this is something client does, not the server, your editor sends only the opened files, clojure-lsp then know what is your project and look for other clojure files

If we add support for other files, it's only affected by the opened files

yes, for bb scripts etc it's usually only the open files that matter

oh i see now, ok

@U027R1ML5RU Why would you not use lein? The alternative is to use deps.edn with e.g. the cognitect test runner. Calling this from babashka would usually be done in bb.edn tasks like this:

(apply clojure "-X:test" *command-line-args*) 

Nice, the question was because lein sometimes takes a lot to load the dependencies and run the test and thought that maybe bb could help speed up for single test running 😊

@U027R1ML5RU I recommend doing this: Install neil: https://github.com/babashka/neil Either using babashka or via the clojure CLI And then invoke:

neil add test

Or does your code run in babashka itself instead of the JVM?

Its a JVM normal project and I was trying to experiment with bb I'll give a look in neil Thanks!

Oh really, I didn't expect that

$ bb -e “(babashka.process/exec [\“echo\” \“ok\“])” prints nothing

bb -e "(babashka.process/exec [\"echo\" \"echo\" \"ok\"])" 

I will try to nail it down later—it’s weird because some programs respond to that missing arg by printing their usage (like ls)

so I’m not 100% sure that’s what’s up

maybe a bug in exec

I'll add some logging

I suppose you're right

@U03J48P76RW You also ran into this right?

I did - but thought it unsurprising, as it's similar to the exec(2) syscall

I think it makes sense to change this behavior though

hmm but then that isn't exec anymore

but i guess ppl never use the feature anyways

is there a reason when you want to pass a different program name + arg0?

not unless you're doing hardcore system programming i suppose

iiuc, you have the file with the binary image, and the name that will appear eg in ps or when the process inspects its own args

yes, change it

So maybe that's the 1% use case and we can have an option:

(proc/exec ["foo" ".."] {:arg0 "bar"})

yes looks good

and arg0 defaults to "foo"

cc @U7RJTCH6J

https://github.com/babashka/process/issues/72

I saw this on the graalvm slack. Anyway, I know of at least one use case where you want a different program name than argv[0] , https://github.com/kovidgoyal/kitty/blob/c8c6f8691f4aa84f4d798428af268319b898798f/kitty/child.py#L257. It is pretty rare though.

Ah yes, this one

It looks like you have a solution you like, but my philosophy for wrapping existing APIs is: 1. provide a wrapper that maps as close as possible to the wrapped function 2. provide a separate, convenience wrapper that uses 1) (preferably with a different, suitable name). For someone who is trying to actually do something tricky that targets the wrapped API, it's much easier to use a minimally wrapped version rather than try to figure out which flags and options you need to pass to a convenience to function to map back to some call the underlying wrapped API function.

if we do want something more exec-like, the function could be (exec binary argv), eg (exec "/bin/blah" ["/bin/blah" "arg"]), and could have a variant of (exec ["/bin/blah" "arg"]) Not familiar with overloading in clj

yes, this is possible, but I think with the :arg0 overridable option you get pretty much the same

it's simpler, and as long as the doc is correct..

We already have these overloads:

(exec [/bin/blah ...])
(exec [/bin/blah ...] {:env ..})

arg0 consistent then, cool

ok, pushed the change to master now

it's not precisely the same, but there is a dynamic *defaults* in the process namespace, so that could be altered or bound to assoc on any desired options