Enter the Monorepo

dkf

Terminal control sequences are generally not a problem for scripts

Shell scripts are simply not very reliable for handling arbitrary input, and there are quite a few programming languages that are much better (but more verbose, so not so great to use as a login shell).

Bulb

@dkf There is a class of tasks that shell is much better at doing. And it's hard to beat the ~300 kB busybox binary with another interpreter too. So I wrote a bunch of rather complex shell scripts over my career (I do revert to python if the complexity warrants it and the two orders of magnitude bigger runtime isn't a problem).

I also started learning powershell and it seems it can be pretty good at similar kind of things. But the .нет runtime isn't exactly small either.

dkf

@Bulb said in Enter the Monorepo:

There is a class of tasks that shell is much better at doing.

Shells are very very good at setting up the details of a pipeline of programs, especially in an interactive context. (Unless you're doing something exotic with having more than just stdin/stdout/stderr channels, but then you're into pain-in-the-asssville for every language I know of.)

Bulb

@dkf Pipelines are a tiny fraction of what I tend to do with shell, and if, they are often something | while read line; do …-style ones. Anything that is heavy on file manipulation is usually simpler in shell than anything else.

dkf

@Bulb said in Enter the Monorepo:

Anything that is heavy on file manipulation is usually simpler in shell than anything else.

If it's really complicated or where the filenames are definitely untrusted, I'll want to script it in something else anyway precisely because I know then that there won't be any weird surprises. yes, I do have shell scripts for stuff, but that's because I know the filenames are non-evil because I chose them for my own files and I prefer to not in my own .

Gribnit

@dkf there"'"s always the option of "excessive" quoting'.'

boomzilla

@dkf said in Enter the Monorepo:

@Bulb said in Enter the Monorepo:

Anything that is heavy on file manipulation is usually simpler in shell than anything else.

If it's really complicated or where the filenames are definitely untrusted, I'll want to script it in something else anyway precisely because I know then that there won't be any weird surprises. yes, I do have shell scripts for stuff, but that's because I know the filenames are non-evil because I ~~chose them for my own files and I prefer to not in my own .~~ don't live inside a blakeyrant.

PleegWat

@Bulb said in Enter the Monorepo:

@dkf The big advantage of find -exec is that it knows where the filenames begin and end. The find -print0 and xargs -0 are GNU extensions, which means you can't use them when your script is supposed to run on MacOS (or any other BSD derivative), some embedded systems using busybox or even that house of cards of a system the Chinese department cobbled together from AOSP the other day that uses “toybox”. And then you are relying on the filenames not containing newlines, and have to be careful to at least handle spaces correctly, because the filenames definitely do contain those. At that point, find -exec becomes easier.

But in general I usually give up and not try to support newlines in filenames. Spaces and other weird characters are doable (but note that xargs defaults to splitting on any whitespace), but newlines are too much of a pain. Too many places don't have a suitable option for nul-separation.

I was going to say -exec ... + is also a GNU extension, but according to the manpage it was actually added to POSIX at some point. Still wouldn't surprise me if it's missing from busybox.