Not really. They’ve been on the stabilising path for about two years now, removing stuff like dataframes from the default feature set to be able to focus on stabilising the whole core language, but 1.0 isn’t out yet and the minor version just went three digits.

And it’s good that way. The POSIX CLI is a clusterfuck because it got standardised before it got stabilised. dd’s syntax is just the peak of the iceberg, there, you gotta take out the nail scissors and manicure the whole lawn before promising that things won’t change.

Even in its current state it’s probably less work for many scripts, though. That is, updating things, especially if you version-lock (hello, nixos) will be less of a headache than writing sh could ever be. nushell is a really nice language, occasionally a bit verbose but never in the boilerplate for boilerplate’s sake way, but in the “In two weeks I’ll be glad it’s not perl” way. Things like command line parsing are ludicrously convenient (though please nushell people land collecting repeated arguments into lists).

Yesterday, I upgraded from 0.101.0 to 0.102.0 and date to-table was replaced equally (actually better) with into record, however it was not documented well in the error. Had to research for 5 to 10 minutes, which does not sound much, but if you get this like every second version, the amount of time adds up quickly.

On a more serious note, NOTHING with more than a little complexity should be written in shell scripts imo. For that, Python is the best, primarily due to how fast it is to prototype stuff in it.

I tend to write anything for distribution in Rust or something that compiles to a standalone binary. Python does not an easily redistributable application make lol

For a bit of glue, a shell script is fine. A start script, some small utility gadget…

With python, you’re not even sure that the right version is installed unless you ship it with the script.

I was chalking it up to some scripting languages just tending to be more popular (like python) and thus having more training data for them to draw from

But that’s a good point too lol

Sounds like a problem for future me. That guy hates me lol

In fairness, this also happens to me when I write the bash script myself 😂

I wonder if there’s a chance of getting rm -rf /* or zip bombs. Those are definitely in the training data at least.

Yes, I have never wrote a piece of code that didn’t do what I thought it would before LLMs, no sir.

For example, how could it know whether cat $foo should be cat "$foo", or whether the script actually relies on word splitting? It’s possible that $foo intentionally contains multiple paths.

Last time I used ShellCheck (yesterday funnily enough) I had written ports+=($(get_elixir_ports)) to split the input since get_elixir_ports returns a string of space separated ports. It worked exactly as intended, but ShellCheck still recommended to make the splitting explicit rather than implicit.

The ShellCheck docs recommended

IFS=" " read -r -a elixir_ports <<< "(get_elixir_ports)"
ports+=("${elixir_ports[@]}")

There actually is an array in any POSIX shell. You get one array per file/function. It just feels bad to use it. You can abuse ‘set – 1 2 3 4’ to act as a proper array. You can then use ‘for’ without ‘in’ to iterate over it.

for i; do echo $i; done.

Use shift <number> to pop items off.

If I really have to use something more complex, I’ll reach for mkfifo instead so I can guarantee the data can only be consumed once without manipulating entries.

This is exactly it. Regex is super simple. The difficulty is maintaining a mental mapping between language/util <-> regex engine <-> engine syntax & character class names. It gets worse when utils also conditionally enable extended syntaxes with flags or options.

The hardest part is remembering whether you need to use \w or [:alnum:].

Way too few utils actually mention which syntax they use too. Most just say something accepts a “regular expression”, which is totally ambiguous.

This is exactly it. Regex is super simple. The difficulty is maintaining a mental mapping between language/util <-> regex engine <-> engine syntax & character class names. It gets worse when utils also conditionally enable extended syntaxes with flags or options.

The hardest part is remembering whether you need to use \w or [:alnum:].

Way too few utils actually mention which syntax they use too. Most just say something accepts a “regular expression”, which is totally ambiguous.

This is exactly it. Regex is super simple. The difficulty is maintaining a mental mapping between language/util <-> regex engine <-> engine syntax & character class names. It gets worse when utils also conditionally enable extended syntaxes with flags or options.

The hardest part is remembering whether you need to use \w or [:alnum:].

Way too few utils actually mention which syntax they use too. Most just say something accepts a “regular expression”, which is totally ambiguous.

I give you that, true. I wish vim had PCRE

This is exactly it. Regex is super simple. The difficulty is maintaining a mental mapping between language/util <-> regex engine <-> engine syntax & character class names. It gets worse when utils also conditionally enable extended syntaxes with flags or options.

The hardest part is remembering whether you need to use \w or [:alnum:].

Way too few utils actually mention which syntax they use too. Most just say something accepts a “regular expression”, which is totally ambiguous.

I know that LLMs are probably very helpful for people who are just getting started, but you will never understand it if you can’t grasp the fundamentals. Don’t let “AI” make you lazy. If you do use LLMs make sure you understand the output it’s giving you enough to replicate it yourself.

This may not be applicable to you specifically, but I think this is nice info to have here for others.

deleted by creator