71–80 of 106 posts
I always hear people talk about writing portable, POSIX compliant shell scripts so they'll work in more environments (assuming those environments are needed, of course), but how often do you run into an environment where you don't have a fairly complete version of Bash available? Genuine open question, I'd be really interested to know what that situation is. Lean container images, embedded, older systems? I'm really…
After years writing bash scripts I stumbled with this line... set -e Which forces the script to exit on first error. This line be in the bible as Genesis 1:1
Just wait till you learn about: set -euo pipefail That should be line two of every bash script.
1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems)
2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD".
Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script.
I always hear people talk about writing portable, POSIX compliant shell scripts so they'll work in more environments (assuming those environments are needed, of course), but how often do you run into an environment where you don't have a fairly complete version of Bash available? Genuine open question, I'd be really interested to know what that situation is. Lean container images, embedded, older systems? I'm really…
https://github.com/zbm-dev/zfsbootmenu/releases/tag/v1.12.0
Don't fall in the trap of thinking things have to be written entirely in bash; it's okay to use other tools to help fill in the gaps.
Earlier quoted context omitted.
> and slower. I like to write posix sh scripts for the sake of portability and, funnily enough, future proofing as I don't like having to maintain stuff against changes that break compatibility, which is something bash does (archlinux is still on an older bash even though debian stable has the latest, because bash 5.2 broke some of archlinux's own scripts. This is why you should not write bash scripts.), but bash bei…
Can you elaborate on your last point? I've never had a problem scripting with Ruby.
https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p... https://nuclearsquid.com/writings/ruby-1-9-what-s-new-what-s...
But the language itself isn't the worst offender, the whole ecosystem around it tends to not even make reasonable attempts at stable APIs. Which isn't helpful with the way dynamically typed languages typically lack in tooling to safely, properly deal with refactoring - there are exceptions like smalltalk I've heard, but overall the cavalier attitude toward delivering a constant treadmill isn't pleasant to me. Of course, some may argue that the reason Perl doesn't suffer as much from it is because it is "dead", but I'll take dead over busywork.
I must say, I don't like Java the language, but Java the platform almost feels like the promised land compared to this. I don't use it to develop myself, but when I ran into an old unmaintained jar and ran it on a current JVM and it just works.. it feels.. fantastic. Absolutely wonderful. The same sort of feeling I also have when I run old games on Wine and it just works. win32 is the stable API I always wished linux had for GUI apps but will never have because the culture is all about CADT.
Earlier quoted context omitted.
> Why does it matter that some use AI tools as a starting point? I rather learn (or iterate) using a proper source of information (like a book, a blog post written by someone with actual knowledge, or even with a more experience coleague). At least for me it seems more productive.
Try pasting a piece of code you don't understand and ask LLM to explain it to you. Then try the same and find a human to explain it to you. Then compare the price (including money and time) and performance of both. I won't believe you made an objective assessment if your conclusion is that either party is the best solution all the time. The point is right now the number of occasions that AI has better price performan…
Why even ask then?
I have tried to use chatGPT a couple of time and many of those times it was wrong, to a point that if I ever use again I'd definitely double check the output(which makes me not bother using it in the first place).
Cute that some people find it useful, I don't, it has no use for me in the state it is today.
Earlier quoted context omitted.
Just wait till you learn about: set -euo pipefail That should be line two of every bash script.
-eu? Yes. -o pipefail? Maybe not, for two reasons: 1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems) 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD". Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script.
I wasn't suggesting for a generic posix shell. It's explicitly for bash.
If you're going to dumb down to pure posix, it's even more painful as you can't even have local function variables.
> 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD".
That type of situation is the exception, not the rule. The more common situation is "foo some-input.txt | bar" and you want it to fail if foo fails.
> Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script.
I'd much rather have that type of failure than an inadvertent continuation of a script when something early in a pipeline failed.
Earlier quoted context omitted.
https://news.ycombinator.com/item?id=35768615 Perhaps dash now has these features but does NetBSD sh or FreeBSD sh have them. What's the point of "pure sh" if it's restricted to specific versions of shells. Opinions may differ but I'd rather learn the "lowest common denominator". I use the same scripts on both Linux and BSD so I need portability. I do not use bash for scripting. It's larger and slower. One source I c…
> and slower. I like to write posix sh scripts for the sake of portability and, funnily enough, future proofing as I don't like having to maintain stuff against changes that break compatibility, which is something bash does (archlinux is still on an older bash even though debian stable has the latest, because bash 5.2 broke some of archlinux's own scripts. This is why you should not write bash scripts.), but bash bei…
> If your scripts do that much work that your shell's speed matters, you should reconsider writing shell scripts and start thinking about using something like perl, python or ruby.
Usually yes.
But there is a small subset of use cases which need a really portable solution. Once I would have recommended to just write it in perl, because it was on virtually all systems. But now perl is getting phased out on some OSs/distros, and with python you never know if you get 2 or 3. Or embedded systems which don't have python/perl in the first place.
My go to solution for slow scripts is usually to limit subshells/forks as much as possible, and/or run it with busybox with the "exec prefers applets" option
edit: it's actually the "run 'nofork' applets directly" option. Can give quite a speed boost compared to bash if you have to call "external" utilities like grep/head/etc.
I always hear people talk about writing portable, POSIX compliant shell scripts so they'll work in more environments (assuming those environments are needed, of course), but how often do you run into an environment where you don't have a fairly complete version of Bash available? Genuine open question, I'd be really interested to know what that situation is. Lean container images, embedded, older systems? I'm really…
I always hear people talk about writing portable, POSIX compliant shell scripts so they'll work in more environments (assuming those environments are needed, of course), but how often do you run into an environment where you don't have a fairly complete version of Bash available? Genuine open question, I'd be really interested to know what that situation is. Lean container images, embedded, older systems? I'm really…
Containers/docker/kubernetes and embedded systems that use e.g busybox is what I’ve seen. Also macOS (used to?) ship ancient bash versions, but there’s recent zsh so that’s mostly fine.