4 ms·

Bash is not a great cross-platform choice. Too many subtle differences. The best way is a scripting language with locked-down dependency spec inside the script

Bash is not a great cross-platform choice. Too many subtle differences. The best way is a scripting language with locked-down dependency spec inside the script. Weirdly .NET is leading the way here.

Imustaskforhelp 8mo ago
Python with uv seems decent in here too.
- kh_hk 8mo ago
  python does EOL releases after 5 years. I guess versions are readily available for downloading and running with uv, but at that point you are on your own. bash is glue and for me, glue code must survive the passage of time. The moment you use a high-level language for glue code it stops being glue code.
oguz-ismail2 8mo ago
>Too many subtle differences. Such as?
- hiccuphippo 8mo ago
  This entire list: https://www.shellcheck.net/wiki/ https://www.shellcheck.net/wiki/
  - oguz-ismail2 8mo ago
    How is any of that a subtle difference between platforms?
- greener_grass 8mo ago
  The tools you will call from your bash script differ in subtle ways between Linux, macOS, MinGW. One good example is `uuidgen`
  - oguz-ismail2 8mo ago
    >uuidgen That's neither a standard CLI utility nor a bash builtin.
    - greener_grass 8mo ago
      Technically maybe, I don't know. But in practice, your bash will use tools like this and break if they are different / missing on a future build host. If using a programming language with locked-down package dependencies, then all you need is the compiler/interpreter and your script will work.
goalieca 8mo ago
Stick to posix shell and it will run anywhere and on anything no matter how old.
tracker1 8mo ago
Hard disagree... I find that Deno shebangs and using fixed version dependencies to be REALLY reliable... I mean Deno 3 may come along and some internals may break, but that should have really limited side effects. Aside: I am somewhat disappointed that the @std guys don't (re)implement some of the bits that are part of Deno or node compatibility in a consistent way, as it would/could/should be more stable over time. I like Deno/TS slightly more because my package/library and version can be called directly in the script I'm executing, not a separate .csproj file.

Bash is not a great cross-platform choice. Too many subtle differences. The best way is a scripting language with locked-down dependency spec inside the script. Weirdly .NET is leading the way here.

Imustaskforhelp 8mo ago

Python with uv seems decent in here too.

kh_hk 8mo ago
python does EOL releases after 5 years. I guess versions are readily available for downloading and running with uv, but at that point you are on your own. bash is glue and for me, glue code must survive the passage of time. The moment you use a high-level language for glue code it stops being glue code.

oguz-ismail2 8mo ago

>Too many subtle differences. Such as?

hiccuphippo 8mo ago
This entire list: https://www.shellcheck.net/wiki/ https://www.shellcheck.net/wiki/
- oguz-ismail2 8mo ago
  How is any of that a subtle difference between platforms?
greener_grass 8mo ago
The tools you will call from your bash script differ in subtle ways between Linux, macOS, MinGW. One good example is `uuidgen`
- oguz-ismail2 8mo ago
  >uuidgen That's neither a standard CLI utility nor a bash builtin.
  - greener_grass 8mo ago
    Technically maybe, I don't know. But in practice, your bash will use tools like this and break if they are different / missing on a future build host. If using a programming language with locked-down package dependencies, then all you need is the compiler/interpreter and your script will work.

goalieca 8mo ago

Stick to posix shell and it will run anywhere and on anything no matter how old.

tracker1 8mo ago

Hard disagree... I find that Deno shebangs and using fixed version dependencies to be REALLY reliable... I mean Deno 3 may come along and some internals may break, but that should have really limited side effects. Aside: I am somewhat disappointed that the @std guys don't (re)implement some of the bits that are part of Deno or node compatibility in a consistent way, as it would/could/should be more stable over time. I like Deno/TS slightly more because my package/library and version can be called directly in the script I'm executing, not a separate .csproj file.