1. 36
  1.  

  2. 12

    I love this tool if only for the fact that getting information on the most up-to-date practices for writing Shell is quite difficult and this tool seems to know all of those best practices.

    1. 2

      I use this on a regular basis to cleanup my bash scripts.

      However what I’m missing: It doesn’t check coding style (unified intention, spaces between operators, pipes etc.). Does anyone know any such tool? I’ve been looking, but haven’t found any.

      1. 1

        https://github.com/mvdan/sh ? (Specifically, the shfmt command provided therein)

      2. 0

        Shellcheck is an impressive project – it does a pretty complete parse using Haskell’s Parsec parser combinator library.

        Although in some sense it was a negative inspiration for Oil [1]. Someone integrated it with the code review system at Google, and mostly what it would tell me to is to quote every variable substitution [2]. I would get an error on every line.

        This is technically correct, but I also thought it was dumb to put so much effort into working around the problems of a crappy language. It would be a lot easier if the language didn’t have this bad behavior in the first place.

        So that is one design principle for the Oil language: no confusion between strings and arrays of strings [3].

        [1] http://www.oilshell.org/ [2] Try !qefs in #bash on freenode [3] http://www.oilshell.org/blog/2016/11/06.html

        1. 2

          The POSIX shell is a programming language with a single type: the string. It would have been better if this single type were an array of strings.

          Have you looked into rc, the Plan9 shell? It’s basically exactly that (and also nicer, more regular syntax than the Bourne shell)

          1. 1

            Yes I encountered rc several years ago, and re-read the paper as I started work on Oil. It’s on my list of shells [1], along with the similar es shell.

            I’ve also looked at the code, but I don’t think I’ve run any scripts with it. I remember it didn’t have word splitting, which is good. It seems like a smaller, cleaned-up POSIX sh, which is good. But it’s also incompatible, which is probably why it wasn’t adopted widely.

            If there’s anything in particular about the rc shell you think would be good in a modern shell like Oil, I’m interested.

            [1] https://github.com/oilshell/oil/wiki/ExternalResources

            1. 1

              I haven’t used rc heavily myself, but the thing I find most appealing is the idea of not having to worry about quoting-induced catastrophes in shell-scripts.

              I’m sure you’ve already got a plan for this, but if “array of strings” is your basic data-type, I hope Oil will make it easy to plumb between the various uses of that structure in shell programming, including arguments given to a command, arguments received from a caller, the results of a find(1) (both \n-delimited and \0-delimited), the inputs to an xargs(1), etc.

              1. 1

                Yes definitely! You will like Oil if I manage to finish it. Help is appreciated. :)

                Though I should mention the functionality of find will likely be builtin. As I mentioned here[1], it’s really an expression language in the style of the [ and [[ language, and the ! -a -o \( syntax is an ugly hack.

                But of course you could still call out to the external GNU find if you want.

                There’s also an argument for xargs and xargs -P in particular being part of the shell. In fact the GNU bash manual refers to GNU parallel [2].

                A shell is a thing that starts processes, and some things get lost if you delegate that task to an external xargs (tracing, stats, time, exit code, etc.)

                But again, Oil work with external xargs if you want as well.

                [1] https://lobste.rs/s/jfarwh/find_is_beautiful_tool

                [2] https://www.gnu.org/software/bash/manual/bash.html#GNU-Parallel