That sounds about right. bb looks at https://github.com/babashka/babashka/blob/master/src/babashka/impl/classpath.clj#L80 places for the classpath and defaults to empty. What was your expectation?

No it sounds wrong, should be nil

according to https://github.com/babashka/babashka/blob/master/src/babashka/impl/classpath.clj#L83 it gives a blank str?

i guess that would also work with nil

As long as it is not adding cwd to the classpath

ive always used babashka.classpath/get-classpath for this which gave nil, so not sure

Ok for a minute I thought I introduced a regressed in the new release but all good then

Don’t know why it would be an empty string if it wasn’t set yet though, I would expect nil

i tried looking for it, not sure where could it be

right, native-image/SubstrateVM seems to have it default to ""

native compile:

System.out.println("'%s' is the classpath".formatted(System.getProperty("java.class.path")));

thats whats probably happening in bb

public class Foo {
    public static void main(String... args) {
        System.out.println(System.getProperty("java.class.path").length()); // => 0
    }
}

System.getProperty("this.doesnt.exist")gives null

Ok weird

do we need the new SCI feature to make this return nil too? 😛 that would probably a breaking change

We can just set it to nil manually at startup but if it isn’t causing any bugs I would just let it be

Hmm might be interesting to actually use the new SCI feature for this to intercept the call but maybe wait a bit

jshell> System.getProperty("java.class.path")
$1 ==> "."

. sounds reasonable since a file under $PWD is reasonable to be considered to be on the classpath, if nothing else was specified (expanding . to an absolute file name would probably be nicer to clients) However, I'm not experiencing a problem, I just assessed cider <-> bb integration (fixing a couple things while I was there) and wanted to make sure there are no weird corners

I have considered adding the PWD as the default classpath if nothing else was specified but so far I haven't made that decision yet. https://github.com/babashka/babashka/issues/1555

the default PWD seems to be specific to Java? Clojure, Kotlin, Scala all say different things

whatever GraalVM has set as a default, this does not affect how bb really works, since the system property is a mere reflection of the reality inside bb, not the source of truth

this won't solve your issue but for consistency: add the map as the first argument to process and the other arguments can be spliced as just string after that

the code looks good to me, not sure what happens

you could wrap this in an extra bash -c '...' to see if that solves the issue

what you are doing with process is pretty similar to shell btw, exactly the same even I think

do you mean: when you quit bb, it should send SIGKILL or SIGINT to the running processes?

i assume it should send SIGINT?

you could try this manually by adding a Shutdown hook which sends SIGINT to those processes... I'm not sure if the JVM / GraalVM does that by default

ok, thanks, i'll try to figure out how to do that. btw wrapping the commands in bash -c '...' did not solve it

(def proc (babashka.process/process {:inherit true} "yes"))

(.addShutdownHook (Runtime/getRuntime)
                  (Thread. ^java.lang.Runnable (fn [] (babashka.process/destroy proc))))

I noticed that when you don't add the shutdown hook and destroy the process, the process keeps running

very annoying with "yes" ;)

oh wait, but this is exactly the same as (def proc (babashka.process/process {:inherit true :shutdown babashka.process/destroy} "yes"))

and seems to work correctly with:

(def proc (babashka.process/process {:inherit true :shutdown babashka.process/destroy} "yes"))

(Thread/sleep 10000)

when I quit it prematurely

so perhaps destroy isn't the right thing to send to your process for some reason, luckily it's configurable

hmm ok, that would make sense

you can view the process builder API here: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Process.html you can get the raw process using (:proc proc) and then try some Java interop. Not sure

you can also get the .pid

though .destroy sounds like it would send SIGINT and destroyForcibly would send SIGTERM

right. I think babashka.process/destroy uses forcible

not sure, might wanna check the source, gotta go for a bit

ok thanks, but btw it uses .destroy

aaah ok

try forcibly then

we could make this an option in bb.process's destroy function

OK I think I know what's happening. I was using :shutdown p/destroy-tree , which was sending SIGINT (?) to both the JVM process and the Chromium process (duh, since it's destroy-tree). But the clean way for handling this was to send :shutdown p/destroy , which sends SIGINT to just the JVM which in turn has a chance to shut down the Chromium process cleanly. So babashka was working entirely as expected, my bad!

But thanks for the quick replies and all the amazing open source contributions! 🙌

Although, this does work fine. I'm happy.

(def cookie (-> (http/post ""
                           {:form-params {:username "user"
                                          :password "password"}
                            :headers     {:referer ""}})
                :headers
                (update-keys csk/->kebab-case-keyword)
                :set-cookie))

(http/get ""
          {:headers {:referer ""
                     :cookie cookie}})

@UPD88PGNT did you find your answer?

oh cookie store, I get it

let me check how that works again

you can pass this https://github.com/babashka/http-client/blob/main/API.md#babashka.http-client/-%3ECookieHandler to your client

if you will then re-use the same client over and over, it will manage the cookies for you

Note that this is a client option, not a request option, so construct a client first

hope that helps

if you want to add anything to do the docs that you found missing, PR welcome