I'm working atm on some bash scripts for HPC and I...
# scripting
e
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?
b
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)
However to get propper autocompletion in IDEA, you need to name your script as *.main.kts
e
then I'd prefer much more to keep my
.kts
extensions 🙂
b
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
Use as ./script Edit as ./script.main.kts
e
nice, but this doubles the entries in the directory, or?
b
Yep
It's just a matter of preference, works either way
e
thanks for sharing though, I'll keep it in mind
interesting
m
I use
*.main.kts
with the shebang line, works well and I don't mind the extra
main.kts
extension.
b
Without shebang you need to invoke it via kotlin explicitly kotlin *.main.kts
m
If there are multiple scripts, I usually use https://ajalt.github.io/clikt/ to parse arguments, have autocomplete, subcommands, etc...
Without shebang you need to invoke it via kotlin explicitly
Yup, that's why I love the shebang
main.kts + shebang + clikt is my winning combo
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
b
Never used clikt myself, so curious what advantages it has when compared to kotlinx-cli?
m
I'm used to it 🙂
More seriously, I think kotlinx-cli doesn't have support for autogenerating bash completions
e
I'm trying to understand what clikt does in practice..
m
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...
b
Parses cli args
m
When I looked at kotlinx-cli it wasn't as feature-packed as Clikt, might have changed though
e
Sorry, but why would I need a lib to parse the cli args?
m
Because it's super tedious doing it correctly
Think of positional vs named args
checking if all args are defined
e
uh, I didn't know that
m
Of course you can ask your users to call your script with
Copy code
./myscript arg0 arg1 arg2 optionalarg3
e
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
m
But it's much nicer to have something like:
Copy code
./myscript --verbose --user foo --password bar install mypackage
And then the user can change the order of args, have a nice interactive help, etc...
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
Although as far as I'm concerned, I'm doing things manually with
ProcessBuilder
when I need it
e
my idea is to move
./myscript --verbose --user foo --password bar install mypackage
into a
./myNewScript
which contains
Copy code
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
m
Ah you don't need clikt for that then
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
If you're running from CI though it doesn't matter at all.
(Did I mention Github Actions has Kotlin builtin these days 🙂 )
e
I saw Louis twitter few posts above
he should definitely spam that in more crowded channels!
I'm gonna switch to github kotlin CI in my next iteration 😄
👍 1
💯 2
m
Not easy to find the correct balance between "bringing awareness" and "annoying everyone" 😅