5 ms·

Is https://github.com/speed47/spectre-meltdown-checker https://github.com/speed47/spectre-meltdown-checker the best tool? Impressive chunk of sh.

izietto 7y ago
What do you have against that script? It's a long script but it's pretty clean and readable
- jakeogh 7y ago
  Oh, nothing! I think it's beyond excellent. I ran shellcheck to see if it was bash or sh and it didnt make a peep:). My Q is just asking if there is another similar quality tool. I see how you could interperit it the other way, thanks for asking.
  - izietto 7y ago
    Oh I see now, I misinterpreted the sense of the question :)
- lecarore 7y ago
  He meant "impressive chunk of bash" (.sh) not "of shit"
  - kick 7y ago
    It's not bash, it's a shell script. bash is not POSIX-compliant. This script is.
    - saagarjha 7y ago
      Bash is POSIX compliant, but it has a number of extensions.
      - kick 7y ago
        No, it isn't. You have to explicitly enable a POSIX-compliant mode: https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html https://www.gnu.org/software/bash/manual/html_node/Bash-POSI...
        saagarjha 7y ago
        That still makes it POSIX compliant…
        kick 7y ago
        If you have to set a mode to make it so, it isn't.
        throwaheyy 7y ago
        No, it is. An x86-64 CPU boots in 16-bit real mode. An explicit option has to be used to switch it to 64-bit long mode. That doesn’t mean that it’s not a 64-bit CPU.
        deleted 7y ago
        [deleted]
        wizzwizz4 7y ago
        When executed as /bin/sh, Bash enables POSIX mode automatically. /bin/bash isn't POSIX compliant by default, but /bin/sh symlinked to /bin/bash is, so you can be sure that #!/bin/sh will be POSIX-like even when implemented by Bash.
        kps 7y ago
        Not entirely. $ echo I am posix compliant &>/dev/null
        deleted 7y ago
        [deleted]
    - quotemstr 7y ago
      A script for bash is a shell script. I've never understood this tic some people have about writing shell scripts executable by strictly minimal POSIX-compliant shells: nobody needs that level of strictness. Everyone has bash. Everyone can easily get zsh too. Why should I spend one minute of my time worry about whether ksh93 or dash or something can run my script when I can just put bash in the shebang line and get access to a much richer feature set? It makes no sense. Portability for portability's sake is a waste of time.
      - saagarjha 7y ago
        I keep my dotfiles bootstrapping script POSIX-compliant; it’s a little bit of a pain but it lets me use it in really stripped down environments.
      - saxonww 7y ago
        It's pretty common to run into environments without bash, or without the bash your script needs. Three examples would be any Docker container based on Alpine (just ash), OpenBSD which ships with (I think) a Korn shell, and macOS which is stuck at Bash 3.x. Similarly, not every Linux distribution puts bash in the same place, e.g. NixOS. So blindly putting `#!/bin/bash` as your shebang will result in a broken script on those systems. You can just install bash or move it around to suit your script, but maybe you're shipping this script for other people to use and can't control their environments. It's easier to make a handful of changes to the script instead. This is why some people care about portability.
      - derefr 7y ago
        There used to be a lot more POSIX OSes; most of them, other than Linux and the BSDs, don’t have Bash, but instead only some other default shell. (Remember the https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem ? Xenix? Solaris?) But the modern reason is https://en.wikipedia.org/wiki/Almquist_shell https://en.wikipedia.org/wiki/Almquist_shell (ash) and its descendant, dash. Busybox environments ship with ash as the only available shell, unless you manually build another shell into the busybox chroot. As well, many initrd/initramfs environments have only one shell, usually dash. When scripting either of these, you have to write pure POSIX scripts. And—mostly due to inertia—this tends to apply to all such environments, no matter their size. My Synology NAS (because it’s technically a busybox env) doesn’t have bash, despite having huge honking disks! Neither does CoreOS (because it’s technically a PXE initramfs env), despite not being intended as a “link-bandwidth-constrained” PXE environment at all. They’re just descended from these “lineages” of OSes that were used on more constrained devices in more constrained times, so their maintainers have kept to the old embedded-system ways. On top of this, as the ash wiki article says, Debian made a choice to make dash their /bin/sh, and then forced all system scripts to use it, thus forcing them to be rewritten to be POSIX-compatible. (I think this was done with goal of lower memory-usage for constrained Debian environments that might still need to install some arbitrary subset of Debian system services.) There was also another kind of pressure, 10-20 years ago, with Linux single-floppy or low-link-bandwidth PXE boot environments wanting to be as slim as possible, and therefore not shipping with bash.
cobbzilla 7y ago
I’m also impressed. For a 5000+ line shell script, it’s pretty well-structured & quite readable.
- kick 7y ago
  You have to go out of your way to make a shell script that isn't easy to read. They're generally more readable at scale than "proper" languages.
  - mratsim 7y ago
    As soon as you deal with env variables, need to support zsh and various shells, it quickly devolves into a hot mess.
    - kick 7y ago
      Ignoring POSIX-compliance does that, yes.
      - throwaway2048 7y ago
        POSIX compliance in no way makes environmental variables in shell scripting more usable and readable, its usually the opposite. I say this as somebody who has written shell scripts for almost 20 years. Constructs like if [ "X${str1}" = "X${str2}" ] to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. Not to mention the hell that is trying to use a user supplied filename safely in shellscript. (for the uninitiated, a unix filename can contain any character, and any sequence of bytes besides / and 0x00, including newlines, backspaces, shell meta-charachters and so many more exciting things)
        YSFEJ4SWJUVU6 7y ago
        > to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. That has less to do with POSIX compliance, as opposed to working around quirks with less-compliant historical implementations. Also, I think you'd have to dig pretty deep to find a test that doesn't support zero-length arguments; you'd be safe as long as you quote your variables. The actual problem of ambiguity arises from variables that are also syntax, like '(', or '!', when using compound expressions (which you should avoid anyway). # this is bad (also obsolete) [ "$var" != foo -a "$var" != bar ] # this is good (and fully POSIX compliant) [ "$var" != foo ] && [ "$var" != bar ] # you probably don't need to care for systems where this was necessary [ "X$var" != Xfoo ] && [ "X$var" != Xbar ]
ac29 7y ago
lscpu contains a pretty good summary of vulnerabilities and seems to be installed on all of the Linux systems I have. Not quite as extensive as the linked script, though.

izietto 7y ago

What do you have against that script? It's a long script but it's pretty clean and readable

jakeogh 7y ago
Oh, nothing! I think it's beyond excellent. I ran shellcheck to see if it was bash or sh and it didnt make a peep:). My Q is just asking if there is another similar quality tool. I see how you could interperit it the other way, thanks for asking.
- izietto 7y ago
  Oh I see now, I misinterpreted the sense of the question :)
lecarore 7y ago
He meant "impressive chunk of bash" (.sh) not "of shit"
- kick 7y ago
  It's not bash, it's a shell script. bash is not POSIX-compliant. This script is.
  - saagarjha 7y ago
    Bash is POSIX compliant, but it has a number of extensions.
    - kick 7y ago
      No, it isn't. You have to explicitly enable a POSIX-compliant mode: https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html https://www.gnu.org/software/bash/manual/html_node/Bash-POSI...
      - saagarjha 7y ago
        That still makes it POSIX compliant…
        kick 7y ago
        If you have to set a mode to make it so, it isn't.
        throwaheyy 7y ago
        No, it is. An x86-64 CPU boots in 16-bit real mode. An explicit option has to be used to switch it to 64-bit long mode. That doesn’t mean that it’s not a 64-bit CPU.
        deleted 7y ago
        [deleted]
        wizzwizz4 7y ago
        When executed as /bin/sh, Bash enables POSIX mode automatically. /bin/bash isn't POSIX compliant by default, but /bin/sh symlinked to /bin/bash is, so you can be sure that #!/bin/sh will be POSIX-like even when implemented by Bash.
        kps 7y ago
        Not entirely. $ echo I am posix compliant &>/dev/null
      - deleted 7y ago
        [deleted]
  - quotemstr 7y ago
    A script for bash is a shell script. I've never understood this tic some people have about writing shell scripts executable by strictly minimal POSIX-compliant shells: nobody needs that level of strictness. Everyone has bash. Everyone can easily get zsh too. Why should I spend one minute of my time worry about whether ksh93 or dash or something can run my script when I can just put bash in the shebang line and get access to a much richer feature set? It makes no sense. Portability for portability's sake is a waste of time.
    - saagarjha 7y ago
      I keep my dotfiles bootstrapping script POSIX-compliant; it’s a little bit of a pain but it lets me use it in really stripped down environments.
    - saxonww 7y ago
      It's pretty common to run into environments without bash, or without the bash your script needs. Three examples would be any Docker container based on Alpine (just ash), OpenBSD which ships with (I think) a Korn shell, and macOS which is stuck at Bash 3.x. Similarly, not every Linux distribution puts bash in the same place, e.g. NixOS. So blindly putting `#!/bin/bash` as your shebang will result in a broken script on those systems. You can just install bash or move it around to suit your script, but maybe you're shipping this script for other people to use and can't control their environments. It's easier to make a handful of changes to the script instead. This is why some people care about portability.
    - derefr 7y ago
      There used to be a lot more POSIX OSes; most of them, other than Linux and the BSDs, don’t have Bash, but instead only some other default shell. (Remember the https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem ? Xenix? Solaris?) But the modern reason is https://en.wikipedia.org/wiki/Almquist_shell https://en.wikipedia.org/wiki/Almquist_shell (ash) and its descendant, dash. Busybox environments ship with ash as the only available shell, unless you manually build another shell into the busybox chroot. As well, many initrd/initramfs environments have only one shell, usually dash. When scripting either of these, you have to write pure POSIX scripts. And—mostly due to inertia—this tends to apply to all such environments, no matter their size. My Synology NAS (because it’s technically a busybox env) doesn’t have bash, despite having huge honking disks! Neither does CoreOS (because it’s technically a PXE initramfs env), despite not being intended as a “link-bandwidth-constrained” PXE environment at all. They’re just descended from these “lineages” of OSes that were used on more constrained devices in more constrained times, so their maintainers have kept to the old embedded-system ways. On top of this, as the ash wiki article says, Debian made a choice to make dash their /bin/sh, and then forced all system scripts to use it, thus forcing them to be rewritten to be POSIX-compatible. (I think this was done with goal of lower memory-usage for constrained Debian environments that might still need to install some arbitrary subset of Debian system services.) There was also another kind of pressure, 10-20 years ago, with Linux single-floppy or low-link-bandwidth PXE boot environments wanting to be as slim as possible, and therefore not shipping with bash.

cobbzilla 7y ago

I’m also impressed. For a 5000+ line shell script, it’s pretty well-structured & quite readable.

kick 7y ago
You have to go out of your way to make a shell script that isn't easy to read. They're generally more readable at scale than "proper" languages.
- mratsim 7y ago
  As soon as you deal with env variables, need to support zsh and various shells, it quickly devolves into a hot mess.
  - kick 7y ago
    Ignoring POSIX-compliance does that, yes.
    - throwaway2048 7y ago
      POSIX compliance in no way makes environmental variables in shell scripting more usable and readable, its usually the opposite. I say this as somebody who has written shell scripts for almost 20 years. Constructs like if [ "X${str1}" = "X${str2}" ] to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. Not to mention the hell that is trying to use a user supplied filename safely in shellscript. (for the uninitiated, a unix filename can contain any character, and any sequence of bytes besides / and 0x00, including newlines, backspaces, shell meta-charachters and so many more exciting things)
      - YSFEJ4SWJUVU6 7y ago
        > to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. That has less to do with POSIX compliance, as opposed to working around quirks with less-compliant historical implementations. Also, I think you'd have to dig pretty deep to find a test that doesn't support zero-length arguments; you'd be safe as long as you quote your variables. The actual problem of ambiguity arises from variables that are also syntax, like '(', or '!', when using compound expressions (which you should avoid anyway). # this is bad (also obsolete) [ "$var" != foo -a "$var" != bar ] # this is good (and fully POSIX compliant) [ "$var" != foo ] && [ "$var" != bar ] # you probably don't need to care for systems where this was necessary [ "X$var" != Xfoo ] && [ "X$var" != Xbar ]

ac29 7y ago

lscpu contains a pretty good summary of vulnerabilities and seems to be installed on all of the Linux systems I have. Not quite as extensive as the linked script, though.