My gut reaction is to rush to the comments to shill my favourite task runner ( mise tasks[1], now with shell aliases[2]!) but pushing past that, the core idea of writing scripts in a file rather than a shell prompt is a great nugget of wisdom. But I disagree with this bit:

"I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file."

What's the difference? Why not version control it, share it with colleagues. Imagine writing a unit test to test a new feature then deleting it when done, what a waste. Ok it's not exactly the same because you aren't using these scripts to catch regressions, but all of that useful learning and context can be reused.

I don't think the language you use for scripting is too important as long as the runtime is pinned and easily available on all engineers machines, perhaps using a toolchain manager like... mise[3].

[1] https://mise.jdx.dev/tasks/ [2] https://mise.jdx.dev/shell-aliases.html [3] https://mise.jdx.dev/dev-tools/

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.

"Just" is exactly made for this, and it is amazing. You write a justfile that is somewhat similar to a makefile but without the painpoints and it provides a CLI interface of commands you want to run

It's almost depressing to me how much this post feels like a breath of fresh air if for nothing else than because it's clearly hand-written, not ghost-written by LLM.

No repetitive short sentences, no "Not X, just Y." patterns, and lots of opinionated statements, written confidently in the first person.

Please more of this.

In the web/js/ts ecosystem, most people use npm scripts in package.json, rather than a custom make.ts. Scripts you launch from there can be in any language, so nothing prevents you from using TS shell scripts if that's your thing.

Another quite standard way of savings your command history in a file that I have seen used in all ecosystems is called "make", which even saves you a few characters when you have to type it, and at least people don't have to discover your custom system, have auto complete work out of the box, etc

How am I the first person to mention fzf?

Just integrate fzf into your shell and use ctrl-r to instantly summon a fuzzy shell history search and re-execute any command from your history!

I cannot imagine going back to using a terminal without this.

I still write plenty of scripts if I need to repeat multi command processes but for one liners just use fzf to reexecute it.

Also in a shared project you can ignore script files with .git/info/exclude instead of .gitignore so you don’t have to check in your personal exclusion patterns to the main branch.

Seriously people if you use a terminal you need the following tools to dominate the shell:

ripgrep, zoxide, fzf, fd

I mostly have my scripts in package.json "scripts" section - but sometimes the scripts invoked will actually be .ts files, sometimes just bash if that makes more sense.

Though, I generally run these scripts using bun (and the corresponding `$` in bun) - basically the same thing, but I just prefer bun over deno

If you want it to be an alternative to shell history then ~/make.ts is better, since that'll be the same wherever you are.

Using `` to interpolate command arguments is very clever! What's missing is a discussion on how you do quoting (for example, how to ls a directory with spaces in name)

Anyway, what kills this for me is the need to add await before every command.

It sounds like at least some of the problems pointed at would be mitigated by using fzf. At least it has greatly improved my terminal ux.

I already do it, but not in TS. There is a scripting language that is as available in most/all (non-Windows) systems as Bash: Python.

Edit: zero-dependency Python.

    life() {
      python3 << EOF
    print(42)
    EOF
    }

This is one of Deno's killer use cases IMO. 100x better than shell scripting and like 5x better than Python scripting. Python should be good for this sort of thing, but it isn't.

Historically we had to use pip which was super janky. Uv solves most of pip's issues but you still do have to deal with venvs and one issue it doesn't solve is that you can't do imports by relative file path which is something you always end up wanting for ad-hoc scripting. You can use relative package paths but that's totally different.

  #!/usr/bin/env -S uv run --script
  #
  # /// script
  # requires-python = ">=3.12"
  # dependencies = ["httpx"]
  # ///
  import httpx
  print(httpx.get("https://example.com"))

  iwr https://example.com

  $b = [BigInt]::Parse('10000000000000000000000000000000000000000000000000')

Heh, I went down that same rabbid hole recently, but in addition to 'shell scripting tasks' also describe a whole C/C++ build in Deno-flavoured TS instead of wrestling with cmake syntax: https://github.com/floooh/fibs - and while at it, also allow to integrate build jobs written in Typescript into the C/C++ build.

...this is the same sort of 'works for me' philosophy as in Matklads post though, it's so heavily opinionated and personalized that I don't expect other people to pick it up, but it makes my day-to-day work a lot easier (especially since I switch multiple times between macOS, Linux and Windows on a typical day).

I'm not sure if Bun can do it too, but the one great thing about Deno is that it can directly import without requiring a 'manifest file' (e.g. package.json or deno.json), e.g. you can do something like this right in the code:

    import { Bla } from 'jsr:@floooh/bla^1';

This is just perfect for this type of command line tools.

Zx is great. Really easy scripting!

This article used Dax instead which also looks fine! Https://github.com/dsherret/dax

I use mise for this as it then also gives you a handy `mise tasks` command so you can see what commands are available and what they do. Mise has been a real gamechanger for my ailing memory.

> I have definitelly crossed the line where writing a script makes sense

...and that was also the one concrete example where it makes sense to have extra dependency and abstraction layer on top of a shell script:)

say you know TS and even if you walk back to where $ is defined, can you tell immediately why $`ls {dir}` gets executed and not just logged?

Does it track file hashes or just timestamps? Critique 2: Better. Shows specific pain point (intellisense) and asks a technical question about caching (hashes vs timestamps). This looks like a solid middle ground between npm scripts and a full-blown CI system. I've always hated the tab syntax in GNU Make, so a typed alternative is appealing.