I'm working atm on some bash scripts for HPC and I...

# scripting

[elect]

I'm working atm on some bash scripts for HPC and I'm really sad on typing bash syntax in a text editor in 2021, so I thought about kotlin.
I'd like to write some small kotlin wrapper for Slurm (the state-of-the-art Api for managing tasks on HPC).
What would you suggest? I'm pretty new to kotlin scripting.. Creating a lib and then users shall just dependsOn from within the scripts?

[Big Chungus]

Why not? Main downside of scripting in kotlin is boot time for first execution as it needs to compile it and download all the dependencies. Otherwise it can be made into bash-like script with simple shebang line

#!/usr/bin/env kotlin

With that and assuming kotlin is on user path, you can run the script like regular executable ./script.kts (you can even remove .kts extension if you want)

[Big Chungus]

However to get propper autocompletion in IDEA, you need to name your script as *.main.kts

[elect]

then I'd prefer much more to keep my .kts extensions 🙂

[Big Chungus]

What I usually do is create a sbolic link to my kts without extension to make it easier to work on as well as use

ln -s ./script ./script.main.kts

[Big Chungus]

Use as ./script

Edit as ./script.main.kts

[elect]

nice, but this doubles the entries in the directory, or?

[Big Chungus]

Yep

[Big Chungus]

It's just a matter of preference, works either way

[elect]

thanks for sharing though, I'll keep it in mind

[elect]

interesting

[mbonnin]

I use *.main.kts with the shebang line, works well and I don't mind the extra main.kts extension.

[Big Chungus]

Without shebang you need to invoke it via kotlin explicitly

kotlin *.main.kts

[mbonnin]

If there are multiple scripts, I usually use https://ajalt.github.io/clikt/ to parse arguments, have autocomplete, subcommands, etc...

[mbonnin]

Without shebang you need to invoke it via kotlin explicitly

Yup, that's why I love the shebang

[mbonnin]

main.kts + shebang + clikt is my winning combo

[mbonnin]

If the main file grows too much then you can think of publishing a lib that's used by multiple files but I haven't reached that limit yet

[Big Chungus]

Never used clikt myself, so curious what advantages it has when compared to kotlinx-cli?

[mbonnin]

I'm used to it 🙂

[mbonnin]

More seriously, I think kotlinx-cli doesn't have support for autogenerating bash completions

[elect]

I'm trying to understand what clikt does in practice..

[mbonnin]

Clikt/kotlinx-cli parse the command line options and do a lot of the boilerplate of verifying mandatory options, displaying help, converting to int, double, boolean flags, etc...

[Big Chungus]

Parses cli args

[mbonnin]

When I looked at kotlinx-cli it wasn't as feature-packed as Clikt, might have changed though

[elect]

Sorry, but why would I need a lib to parse the cli args?

[mbonnin]

Because it's super tedious doing it correctly

[mbonnin]

Think of positional vs named args

[mbonnin]

checking if all args are defined

[elect]

uh, I didn't know that

[mbonnin]

Of course you can ask your users to call your script with

./myscript arg0 arg1 arg2 optionalarg3

[elect]

that's exactly why I'm trying kotlin script. I'd like to move away from a traditional super long line with arguments to a DSL constructs

[mbonnin]

But it's much nicer to have something like:

./myscript --verbose --user foo --password bar install mypackage

[mbonnin]

And then the user can change the order of args, have a nice interactive help, etc...

[mbonnin]

Clikt is really about parsing arguments. If you want to call processes do redirections, etc.. take a look at https://github.com/jakubriegel/kotlin-shell

[mbonnin]

Although as far as I'm concerned, I'm doing things manually with ProcessBuilder when I need it

[elect]

my idea is to move ./myscript --verbose --user foo --password bar install mypackage into a ./myNewScript which contains

whatever {
   verbose = true
   user = foo
   password = bar
   install(mypackage)
}

taking advantage of statically typed code, IDE support, enums, adding additional logics (such as exclusive options), etc etc

[mbonnin]

Ah you don't need clikt for that then

[mbonnin]

You sure can do that. One advantage of having parameters like "verbose" is that you don't have to check them in git. It's under the user control

[mbonnin]

If you're running from CI though it doesn't matter at all.

[mbonnin]

(Did I mention Github Actions has Kotlin builtin these days 🙂 )

[elect]

I saw Louis twitter few posts above

[elect]

he should definitely spam that in more crowded channels!

[elect]

I'm gonna switch to github kotlin CI in my next iteration 😄

[mbonnin]

Not easy to find the correct balance between "bringing awareness" and "annoying everyone" 😅