The pain of creating 'universal' shell scripts

Zucca

TL;DR; - You cannot know which shell interpreter lies at /bin/sh and many common cli tools work differently between publishers/vendors/organizations/developers.

Lately I've been creating scripts that should just work about everywhere. Some may say I'm obsessed with compatibility. One such script is on my phone. Based on the environment it tries to run the script using busybox sh and use as much of its internal commands as possible (to be able to run as fast as possible, although it "won" the speed contest I performed, it did it just barely). If its functions cannot locate busybox, it tries to use as many native (from android system) programs as possible, assuming these were compiled against the specific hardware of the phone.

When I write a POSIXy compliant script, I usually test it with busybox shell as it is little more limited than POSIX sh (afaik) and is pretty common among some minimal and embedded systems.
But then... it isn't still a walk in a park after that. I can pretty safely (foreshadowing...) assume that if I use short options (-v) instead of the gnu long ones (--verbose) the command will run correctly in an environment with coreutils and inside busybox sh.
However! There are differences. In fear of sounding paranoid it feels like some differences were made intentionally.

For example I can almost get the same output from busybox ps and coreutils ps by running ps -Ao pid,user,tty,comm ... but not quite. Busybox limits column width. :evil:

User 'messagebus. turn into 'messagebu' and many comm columns get shortened too. ARGH! So to get the exact same process output on both ways I guess I need to resort in crawling trough /proc/[0-9]+/. Except that busybox' find uses different regex matching then coreutils' find. Oh great...
So for this particular case I came up with this:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21637

While GNU may not always make the best decisions, their tools are generally more capable than a pure POSIX system, and those extra features are often useful. I think this is one reason so many people assume GNU tools, rather than coding to pure POSIX.

You might improve your script's performance a bit if you use a built-in read instead of cat for loginuid. Also, prefer cheap tests over expensive ones, so test loginuid before you try to resolve the exe's path. If loginuid fails, you will skip showing the process, and thus skip calling realpath.

Crawling through /proc is inherently racy, so you may get surprising results if a process exits while you are running.

Zucca · Posted: Sun Jul 16, 2023 6:37 pm Post subject:

GDH-gentoo

szatox · Advocate Joined: 27 Aug 2013 Posts: 3137

Zucca

stefan11111 · l33t Joined: 29 Jan 2023 Posts: 922 Location: Romania

If portability is the concern, can't you use something like c89?
I imagine you'll have a better time that trying to do this with shell.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"

szatox · Advocate Joined: 27 Aug 2013 Posts: 3137

Well, you clearly are already aware of the fact that you're overdoing it, so how 'bout changing the approach a little bit?
It doesn't matter how hard you try, you will never achieve 100% of the objective "script that runs everywhere". Whatever you do, I can always throw you some case where it breaks. E.g. it's not going to work on windows :lol:

Wait, what? What did you say? You mean that windows is out of scope? Ah, right... Well, thank you, that's exactly my point.
What is the purpose of the script you're writing?
What tools are available on the systems to which this script is applicable?
Answering those questions should help define "good enough"... And then just ignore the rest of the world.

Zucca · Posted: Sun Jul 16, 2023 9:44 pm Post subject:

geki · Posted: Mon Jul 17, 2023 8:24 pm Post subject:

Did you try to set ash's terminal width with

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

stefan11111 · l33t Joined: 29 Jan 2023 Posts: 922 Location: Romania

geki · Posted: Tue Jul 18, 2023 8:54 pm Post subject:

I played a bit with my ps tools from busybox and procps-ng. I recommend to use args over comm to get the process command in full length. You can set the width of the columns of the output of ps by setting its header name.

Zucca

Zucca · Posted: Wed Jul 19, 2023 8:47 am Post subject:

flexibeast

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

Zucca · Posted: Mon Jul 31, 2023 7:24 am Post subject: is_int?

One silly thing with *nix shells is to check if some variable is an integer. The common way would be

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

The ${...} machinations are nice, but I can never remember them as I don't use them often. As such, I'll typically only use them when it seems worth the added effort. I've never written (or needed to) a script where performance was a factor. I've written some one-offs that could be improved if they were needed repeatedly, but that's about it.

Another possibility (seems to work with busybox and toybox).