Interesting question! I hope we get lots of answers. find - babashka.fs/glob grep - clojure.core/filter sed and awk - some combination of glob and filter. You can always babashka.process/shell out to find, grep sed and awk. I’ve ported a few bash scripts to babashka, and I find that doing as little as possible in each step is a good idea.

Specific examples of using grep, sed, awk and find would help — then we could see (specifically) how those could be implemented in Babashka.

find working/$RELPATH/Lifecycle/ansible -type f -name '*.yml'| xargs grep -liE 'report PROPERTIES'

oooh, this looks like a nice thread-last (`->>`)-pipe! I’d start with a babashka.fs/glob for the files, then run filters with babashka.fs predicates for files, and file name checks. Xargs would be a map with a new function from each file to a slurp, clojure.string/split-lines and a filter. Not sure what the grep args are doing, but I’d assume that could be a predicate option. I don’t have the time to write an example right now, so you’re (unfortunately) just getting loose ideas (yet)!

(perhaps other babashka-ers reading this thread can take that as a call to action)

Too add to what @U3X7174KS, babashka has all you need, and IMO its offerings are better (i.e. more reliable, easier to maintain)

Teodor's answer should give you a few pointers, a few others in https://presumably.de/how-to-do-things-with-babashka.html

It's a bit of a mindset shift, as you're using a real programming language now, which is a bit more verbose but also more reliable, more modular, etc etc

find is just a map over fs/glob

anything in particular you got stuck with?

I will give it a go.

It is these unix tools that I got used to that if I could get into babashka mode might mean I don't end up with a mixture of the two.

The other tool I heavily use if Sed.

clojure.string/replace is a good replacement

@U0J8XN37Y can you confirm this is different behavior than clojure's?

I’ll try. Have to say I”m so used to seeing the the java code in a lot of projects at work and knowing that this works with k8s pod lifecycle management I did not second guess it. Will try and report back

It seems clj / java does execute the shutdown hook on SIGTERM. Maybe this is an issue with native image, I'll run a test

Yes, that’s what I found out too. I found a way using signals to trigger an system exit which works, but looks a bit hacky

yeah, I was going to propose that as a workaround :)

👌:skin-tone-4:

I think if there’s no signalHandler for TERM it will will be treated as a INT, but might be wrong

Seems to happen with small repro as well. I asked here in the native image channel now. https://graalvm.slack.com/archives/CN9KSFB40/p1681927638938879

@U0J8XN37Y I think this fixes it: https://github.com/babashka/babashka/commit/63102eca863579effd8f4b4c639d3f2bfac8e687 Once this build finishes, you can try the dev-build version:

bash <(curl ) --dev-build --dir /tmp

Wow! Awesome, thx for the fix!

Was looking into how to fix it myself, but sadly I’m pretty new to graalvm

If you're not on Windows you should be able to test it

since the other builds already have finished

is the customer running with jdk8?

it is by design that jdk8 is supported, but only if you compile on jdk8

Yep, this one was running Java 8

I’m wondering if it would be better to do this check at runtime, maybe cache with a delay or similar. For us, this means we would need to exclude babashka.process from AOT compiling (not sure if that’s possible). Not a big deal, as we now added a check to check for a minimum version, but it was surprising nontheless

I think I've already gone out of my way to support jdk8. If I would make any changes to this, I'd be tempted to drop support for jdk8 altogether

Makes sense!

@U07M2C8TT are you a colleague of @U922FGW59 maybe?

given https://github.com/babashka/process/issues/111

He is :)

Yeah, sorry for the duplicate questions… we were both looking at the same thing