5 ms·
This is the way. Shell makes for a terrible scripting language, that I start regretting choosing usually around the time I have to introduce the first `if` into
by pzmarzly 9mo ago
This is the way. Shell makes for a terrible scripting language, that I start regretting choosing usually around the time I have to introduce the first `if` into my "simple" scripts, or have to do some more complex string manipulation.
At least nowadays LLMs can rewrite Bash to JS/Python/Ruby pretty quickly.
- frizlab 9mo agoI use swift! I even (re-)wrote swift-sh[0] to make it possible to import external modules in a script (à la uv). [0] https://github.com/xcode-actions/swift-sh https://github.com/xcode-actions/swift-sh
- kh_hk 9mo agoWell, at least I will be able to run my bash scripts in 5 years
- gf000 9mo agoFor some quality of "run", because I'm hella sure that it has quite a few serious bugs no matter what, starting from escapes or just a folder being empty/having files unlike when it was written, causing it to break in a completely unintelligible way.
- deleted 9mo ago[deleted]
- kh_hk 9mo agoI guess we have wildly different expectatives of what a language is responsible for and what not.
- pzmarzly 9mo agoFair. My bash scripts only broke 3 times over the years: - when ls started quoting filenames with spaces (add -N) - when perl stopped being installed by default in CentOS and AlmaLinux (had to add dnf install -y perl) - when egrep alias disappeared (use grep -E)
- greener_grass 9mo agoBash 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 9mo agoPython with uv seems decent in here too.
- kh_hk 9mo agopython 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 9mo ago>Too many subtle differences. Such as?
- hiccuphippo 9mo agoThis entire list: https://www.shellcheck.net/wiki/ https://www.shellcheck.net/wiki/
- oguz-ismail2 9mo agoHow is any of that a subtle difference between platforms?
- greener_grass 9mo agoThe tools you will call from your bash script differ in subtle ways between Linux, macOS, MinGW. One good example is `uuidgen`
- 9mo ago
- g947o 9mo agoI don't know Ruby, but chances are that your Python/JavaScript scripts are going to run in 5 years as well, if you stick to standard library.
- ChrisGreenHeur 9mo agoand then your mamba changes
- nilamo 9mo agoWhat's that even mean
- g_delgado14 9mo agono one knows what it means, but it's provocative!!
- ChrisGreenHeur 9mo agohttps://github.com/mamba-org/mamba https://github.com/mamba-org/mamba
- dmix 9mo agoJust don't use any NPM libraries (if possible) and you'll be fine. I personally wouldn't use typescript for this sort of thing.
- sroussey 9mo agoWhy not? You can have bun or even node these days run it directly.
- dmix 9mo agoI've been using node for a decade now and I've had to update NPM libraries a number of times as Node itself upgraded. I have a feeling it will get a lot more stable with ESM and the maturity of the language but if you're writing something you need to run 5-10yrs from now I wouldn't touch a library unless it's simple and has few of it's own dependencies.
- norir 9mo agoI consider luajit a much better choice than bash if both maintainability and longterm stability are valued. It compiles from source in about 5 seconds on a seven year old laptop and only uses c99, which I expect to last basically indefinitely.
- sureglymop 9mo agoAgreed. The shell is great for chaining together atomic operations on plaintext. That is to say, it is great for one liners doing that. The main reason probably isn't how it all operates on plain text but how easy it makes it to start processes, do process substitution, redirections, etc. As soon as you have state accumulating somewhere, branching or loops it becomes chaotic too quickly.
- wmwragg 9mo agoI generally use AWK as my scripting language, or often just write the whole thing directly in AWK. It doesn't change, is always installed on all POSIX platforms, easily interfaces with the command line, and is an easy to learn small language.
- camilomatajira 9mo agoCould you please provides examples on how to do it? Specially given that the operating system calls dont return back the output of the command? Thx
- lelanthran 9mo ago> This is the way. Shell makes for a terrible scripting language, that I start regretting choosing usually around the time I have to introduce the first `if` into my "simple" scripts, or have to do some more complex string manipulation. I suppose it can be nice if you are already in a JS environment, but wouldn't the author's need be met by just putting their shell commands into a .sh file? This way is more than a little over-engineered with little benefit in return for that extra engineering. The reasons (provided by the author) for creating a Make.ts file is completely met by popping your commands into a .sh file. With the added advantage that I don't need to care about what else needs to be installed on the build system when I check out a project. I just don't see the advantages.
- dsherret 9mo agoThe benefit is you can easily scale the complexity of the file. An .sh file is great for simple commands, but with a .ts file with Deno you can pull in a complex dependency with one line and write logic more succinctly.
- lelanthran 9mo ago> The benefit is you can easily scale the complexity of the file. An .sh file is great for simple commands, but with a .ts file with Deno you can pull in a complex dependency with one line and write logic more succinctly. The use-case, as per the author's stated requirements, was to do away with pressing up arrow or searching history. Exactly what benefit does Make.ts provide over Make.sh in this use-case? I mean, I didn't choose what the use-case it, the author did, and according to the use-case chosen by him, this is horrible over-engineered, horribly inefficient, much more fragile, etc.
- tracker1 9mo agoThe differences between different environments can vary a lot... many shell scripts rely on certain external programs being available and consistent... this is less true across windows an mac and can vary a lot. I've found that Deno with TS specifically lets me be much more consistent working on projects with workers across Windows, Mac and Linux/WSL.
- amterp 9mo agoThis is exactly the frustration that lead me to write Rad [0] (the README leads with an example). I've been working on it for over a year and the goal is basically to offer a programming language specifically for writing CLIs. It aims for declarative args (no Bash ops parsing each time), automatic --help generation, friendly (Python-like) syntax, and it's perfect for dev build scripts. I'll typically have something like this: #!/usr/bin/env rad --- Dev automation script. --- args: build b bool # Build the project test t bool # Run tests lint l bool # Run linter run r bool # Start dev server release R bool # Release mode filter f str? # Test filter pattern filter requires test if build: mode = release ? "--release" : "" print("Building ({release ? 'release' : 'debug'})...") $`cargo build {mode}` if lint: print("Linting...") $`cargo clippy -- -D warnings` if test: f = filter ? "-- {filter}" : "" print("Running tests{filter ? ' (filter: {filter})' : ''}...") $`cargo test {f}` if run: bin = release ? "target/release/server" : "target/debug/server" $`./{bin}` Usage: ./dev -b (build), ./dev -blt -f "test_auth" (build, lint, test auth), ./dev -r (just run). Actively being developed! [0] https://github.com/amterp/rad https://github.com/amterp/rad
- oguz-ismail2 9mo agoDoes this spawn a new shell for every instance of $`...`?
- amterp 9mo agoYep each one is a fresh session. Are you asking because you'd like a persistent one?
- pxc 9mo agoI've been working a lot in fairly complex shell scripts lately (though not long— not much over 1000 lines). Some of them are little programs that run locally, and others drive a composable cloud-init module for Terraform that lets lets users configure various features of EC2 hosts on multiple Linux distribution without writing any shell scripts themselves or relying on any configuration management framework beyond cloud-init itself. With the right tooling, it's not as bad as you'd think. For both scripts, everything interesting is installed via Nix, so there's little reliance on special casing various distros', built-in package managers. In both cases, all scripts have to pass ShellCheck to "build". They can't be deployed or committed with obvious parse errors or ambiguities around quoting or typos in variable names. In the case of the scripts that are tools for developers, the Bash interpreter, coreutils, and all external commands are provided by Nix, which hardcodws their full path into the scripts. The scripts don't care if you're on Linux or macOS— they don't even care what's on your PATH (or if it's empty). They embrace "modern" Bash features and use whatever CLI tools provide the most readable interface. Is it my favorite language? No. But it often has the best ROI, and portability and most gotchas are solved pretty well if you know what tools to use, especially if your scripts are simple.
- pjmlp 9mo agoA lesson I learnt during the 90's already switching into Perl instead, somehow people keep writing pieces of wonder in plain shell scripts.