[HN Gopher] Type-ish - A runtime type checker for bash, in bash
       ___________________________________________________________________
        
       Type-ish - A runtime type checker for bash, in bash
        
       Author : mgliwka
       Score  : 70 points
       Date   : 2022-06-19 08:01 UTC (15 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | MauranKilom wrote:
       | > the builtin types are:
       | 
       | > [...]
       | 
       | > boolean: a shortcut for returning a number (as numbers are
       | booleans).
       | 
       | Can someone explain? I can understand booleans being numbers
       | (e.g. #define TRUE 1 in C), but how are numbers booleans in bash?
        
         | EdSchouten wrote:
         | Booleans in shell scripts are little more than zero (true) and
         | non-zero (false) exit codes.
        
           | MauranKilom wrote:
           | Ok, right. But then it should still say either "booleans are
           | just numbers" or "numbers can be interpreted as booleans,
           | i.e. are truthy or falsy".
        
             | ancientsofmumu wrote:
             | It's not that cut & dry, as bash is doing evaluations; 0
             | and 1 can both be "true" if simply used without an
             | evaluation, but add logic and it starts to matter (grep
             | returns 0 if hit, 1 if not).                   [[ 0 ]] &&
             | echo "hit 0"         [[ 1 ]] && echo "hit 1"         grep
             | -q 127 /etc/hosts && echo "hit grep"         grep -q 128
             | /etc/hosts || echo "miss grep"
        
       | encryptluks2 wrote:
       | I used to somehow think Bash scripts were ideal given that they
       | were fairly transparent, but I'll take a Go app or Rust program
       | anyday now over something written in shell script. shfmt is an
       | example.
        
         | usrbinbash wrote:
         | Well, they are fairly transparent.
         | 
         | The problem is, they have a tendency to suddenly get horribly
         | intransparent when they grow larger than maybe a few dozen
         | lines.
        
       | goncaloo wrote:
       | This looks pretty cool!
       | 
       | I can't ever imagine using it tho :) If my bash scripts are so
       | complex or critical that I feel the need to type check, I will
       | probably use another scripting language where I can do that more
       | easily while still having readable code.
        
         | kreetx wrote:
         | If you ever check your arguments for any properties then this
         | could still help, you'll have a systematic approach instead of
         | an ad hoc one.
        
       | sam_ezeh wrote:
       | >It is also a very cursed idea taken way too far, and I do not
       | apologize for it
       | 
       | Agreed XD
       | 
       | It's a really nice idea but I cannot ever see myself writing bash
       | like this
        
       | nchase wrote:
       | This is wild. Bravo to the author! (For the tool, and also for
       | really funny documentation and commit history)
        
       | unhammer wrote:
       | Since no one has said it yet, please always use
       | https://www.shellcheck.net/ on your scripts, you don't want to be
       | That Guy https://github.com/ValveSoftware/steam-for-
       | linux/issues/3671
        
         | synergy20 wrote:
         | shellharden is also great, that semi-automate the process to
         | conform with shellcheck
        
         | rob_c wrote:
         | Oh I do love reading those... Shame that shell scripting is
         | still treated as mysterious command line voodoo, even Microsoft
         | has Powershell now showing how powerful the concept is that
         | even they couldn't avoid it entirely
        
         | bravetraveler wrote:
         | General recommendation specifically for the Valve-like case:
         | set -o nounset
         | 
         | You can check variables as many ways you want, just do this too
         | - safety net in case there's an eventual gap
        
         | doliveira wrote:
         | I'm probably being too judgemental, but I don't get how people
         | are so nonchalant about mutability and potentially destructive
         | commands. Even in a Github Gist I'm scared enough to set -euo
         | pipefail, put half a dozen checks before removing a folder...
        
         | j1elo wrote:
         | And use the so-called "Bash unofficial strict mode", as
         | described elsewhere.
         | 
         | I prefer this summary of it, because the original includes
         | stuff like changing IFS (the fields separators) which I agree
         | with the Gist author to not include, because it is a Bad Idea
         | to blindly suggest it universally.
         | 
         | EDIT: This gist:
         | 
         | https://gist.github.com/robin-a-meade/58d60124b88b60816e8349...
        
         | Spivak wrote:
         | You should also probably add either nullglob or failglob
         | depending on your use case.
         | 
         | I would also add dotglob because it's rarer for me to want only
         | non-hidden files than it is for me to want all files.
        
         | tyingq wrote:
         | Ah, wow. I like that they ported the accidental behavior
         | deliberately into Windows:
         | 
         |  _Warning: The uninstallation process deletes the folder Steam
         | was installed to to ensure it is fully uninstalled. If you
         | accidentally installed Steam to a folder containing other data,
         | for example C:\Program Files (x86)\ instead of C:\Program Files
         | (x86)\Steam\\... "_
        
       ___________________________________________________________________
       (page generated 2022-06-19 23:01 UTC)