Threads for ilfigliodellaparolaavuoto

  1. 1

    I am stuck with an Air 2012 for similar reasons, although for my needs this laptop still works. I am mostly disappointed on the software side, the entire apple ecosystem feels less friendly than 10 years ago for power users or developers. I used to write my apps for my iphone, I stopped doing so when required to renew certificates every week. Also there are too many annoyances using third party software or when trying to access personal folders.

    1. 17

      And the corollary: The first line of your shell script should be


      If you need bashism for something complex that needs to be maintainable, use #!/usr/bin/env bash as the article suggests, but 99% of ‘bash’ scripts that I’ve seen are POSIX shell scripts and work just fine with any POSIX shell.

      1. 16

        And the corollary: The first line of your shell script should be

        I disagree, enormously. There are some specific, isolated, and extremely uncommon situations where it’s important you target sh; the rest of the time, you are constraining yourself for no appreciable benefit.

        In particular, if you did go and change the interpret to /bin/sh, you also need to change the second line, since (at least) pipefail is a bashism.

        1. 3

          I think being constrained to a smaller and simpler set of features is the appreciable benefit.

          This applies doubly if somebody is going to have to maintain this code.

          1. 2

            One does not necessarily follow the other. I’ve seen horrific apparently-posix-sh scripts with the most unmaintainable contortions to avoid using a widely known bash feature that would make the code far more legible. Eg bash arrays.

            1. 1

              I don’t disagree; often there is no nice way in posix sh to do something that a bash array could. But I’ve found that once you begin to feel a desire for any kind of data structure in your program, it’s probably time to switch to a more robust programming language than (ba)sh.

              1. 2

                I generally agree. When I look back at my professional career (16 years and counting), I’ve spent a remarkable amount of it essentially writing bash scripts. Which is surprise.

                Most recently, for containers which can’t have a larger interpreter inside them for space reasons, ruling out Python etc

          2. 1

            In particular, if you did go and change the interpret to /bin/sh, you also need to change the second line, since (at least) pipefail is a bashism.

            Thanks. I have little experience with non-BASH shells and I didn’t want to assume that this would work in on a non-BASH script. Good to learn that it doesn’t.

          3. 14

            Good POSIX shell reference here:


            1. 5

              Fair point. I am trying to target the 100%. It feels to me that’s it’s best to program against bash than risk in failing in a corner case on a shell which I never tested my script against.

              1. 2

                For 99% of shell scripts its a non issue. A lot of people use things like arrays in bash when simple quoted strings work on every shell. Writing portable across multiple bourne shell interpreters is easier than you think it is. Most of my scripts run under any of ksh/zsh/bash/sh with zero changes. And testing wise… there isn’t much to test tbh, outside of -o pipefail only works for zsh and bash. Generally the -u catches those cases anyway.

                What kind of corner case are you thinking of? Also as yule notes, run shellcheck on your scripts when writing them. That will reduce your edge cases significantly.

                1. 4

                  The annoying thing is that bash doesn’t disable bash extensions when invoked as sh. A couple weeks ago, I had to debug why a script written by a colleague didn’t work. It turned out that he used &> to redirect both stderr and stdout to a file. I didn’t even know this existed, and he didn’t even know it wasn’t portable. The nasty part is that this doesn’t cause an error. Instead, foo &> bar is parsed as foo & (not sure what happens to the > bar bit; file is created but not hooked up to stdout of foo), which causes race conditions with whatever comes next relying on foo having already completed.

                  Of course, with #! /usr/bin/env bash in the script, this wouldn’t have been a problem on my machine, but I maintain that it would be more productive if bash disabled all of its non-POSIX extensions when invoked as sh. More commonly, you see people use [[ ... ]] instead of [ ... ]. I’m still not even sure how [[ is different from [.

                  1. 1

                    I’m still not even sure how [[ is different from [.

                    I vaguely know that and I switch out Bash for Python as soon as even simple string or array manipulation kicks in. My reasoning is that programs always become more complex over time. You start with simple string manipulation and soon end up with edge case handling and special cases. Best to switch to a language like Python which supports that.

                    1. 1

                      I think (among other things) [[ disables word splitting, i.e. you can use variables without needing to quote them. At least that’s how it works in ksh.

                2. 4

                  Are they though? POSIX shell is so extremely limited that most scripts end up with some bashisms in them, if only to send a string to a program’s stdin. foo <<< "$var" is so much nicer than printf "%s" "$var" | foo (and no, you can’t use echo because POSIX is so vague that you can’t correctly tell echo to treat an argument as a string and not an option in a portable way)

                  I’ve made the mistake of thinking my script is POSIX, using #!/bin/sh, and then hearing from Ubuntu users that it doesn’t work in Dash. (I’ve also had problems where my script actually is POSX, but dash is so riddled with bugs that it still didn’t work on Debian-based systems.)

                  1. 6

                    That’s why it’s a good idea to always lint your scripts with shellcheck. It will catch all bashisms when you set shellbang to /bin/sh

                  2. 3

                    In which case -o pipefail is undefined, at least according to shellcheck.

                    In any case I find running shellcheck on shell scripts to be really valuable. You don’t have to follow it blindly, but it has some very good hints.

                    1. 1

                      shellcheck is my favorite linter for bash scripts as well. It sometimes feels a bit aggressive but I prefer that as opposed to making a mistake.

                    2. 2

                      I respectfully disagree, using the /usr/bin/env method requires bash, so you can use all the bashisms you want, and require users of your scripts to have bash installed.

                      For 95% (wild-ass guess) of Unix users, this is the case. For the rest, if you’ve stated the requirements clearly, they’ll either accept the requirement or form a large enough crowd with pitchforks to force you to change.

                      1. 2

                        *BSD, Solaris, and Android don’t have bash installed by default and it isn’t part of their base systems so it isn’t available until /usr/local is mounted and can’t be used anywhere in early boot. Ubuntu uses dash as /bin/sh, but does install bash by default. Embedded Linux systems typically use busybox or similar and so don’t have bash.

                        95% of Unix users probably covers all Android users, so that’s not a particularly useful metric. The interesting metric is the set of people you expect to use your script. If it’s GNU/Linux users, that’s fine. If it’s people running large desktop / server *NIX systems (macOS, *BSD, Linux), bash is probably available easily but it may not be installed on any given system so you’ve added a dependency.

                        By all means, if you depend on bashism then use bash. In general, I’ve found that my shell scripts fall into two categories:

                        • Simple things, where the POSIX shell is completely adequate and so there’s no reason to use anything other than /bin/sh.
                        • Complex things where I actually want a rich scripting language. Bash is a pretty terrible scripting language, but it’s a much lighter weight dependency than something like Python so I’ll often use bash for these things.

                        I use bash as my interactive shell on FreeBSD, so I don’t really mind having it as a dependency for things, but I consider it somewhat impolite to add dependencies in things I distribute when I don’t really need them.

                      2. 2

                        Why #!/usr/bin/env bash as opposed to #!/bin/bash tho? I’ve seen that done for ruby scripts, and I figured it’s because maybe ruby is in /usr/local/bin, but isn’t bash always in /bin/bash?

                        1. 10

                          Not on all systems. e.g. on FreeBSD and OpenBSD it’s /usr/local/bin/bash.

                          1. 7

                            Or Nix and Guix, which have them in some entirely different place (e.g. on Guix is something like /gnu/store/.../).

                          2. 4

                            in the BSDs it should be under /usr/local/bin or /usr/pkgs/bin. MacOS ships an old version of bash and one might want to install a newer version from homebrew, which goes under /usr/local/bin

                            1. 1

                              Using env bash let me both use a newer homebrew bash on Macs, and keep the script working on Linux machines, and possibly even Windows via WSL. On Macs the newer homebrew bash was needed for a switch statement, if memory serves.

                              For ruby, chruby lets one install multiple versions on one system, and flip between them.

                          1. 2

                            Couple of questions:

                            • how do I install updates? I tried freebsd-update but it seems not to be supported on it. make buildworld also failed (I don’t have the rpi3 it here right now and don’t remember). Am I required to cross compile the system for security updates?
                            • does the audio (on board jack) work?
                            1. 3

                              Unfortunatelly ARM32 and ARM64 are not Tier 1 architectures (only i386 and amd64 are) so there are not updates with freebsd-update. This will change with introduction of FreeBSD 13.0-RELEASE … at the beginning of 2021 I think.

                              1. 2

                                It’s understandable they don’t provide binary updates, but I was surprised I couldn’t just make a buildworld from the pi itself following this. I have to admit I haven’t looked too much in details, I will try again later.

                                1. 1

                                  The make buildworld process sometimes fails even on *-RELEASE versions.

                                  Submit a bug here - - or describe your problem on the FreeBSD Forums - - you will get lots of help there.

                            1. 1

                              I found some errors in my openings, but sometimes I don’t agree with chesscoach. An example would be 1.c4 g6 2.g3 and now chesscoach tells me g3 is -1.4 points wrong while 2. g4 is the correct choice. I might want to play an english or english-like opening, and -1.4 seems too much.

                              1. 1


                                As a result of your feedback, we made some improvements to our website and released an update just now :)

                                The new features are:

                                • You can now analyze games with a specific time control class (for example: blitz games)
                                • We’ve expanded our openings dataset so opening moves don’t get reported as mistakes
                                • You can filter mistakes by the minimum number of games that you made them in
                                • Added ability to report mistakes as not being mistakes

                                Thanks again for your valuable feedback :)

                                Cheers !