1. 14
  1.  

  2. 7

    I hope I’m not beating a dead horse, but the point of the Oil shell [1] is to get rid of this debate.

    I realized that not everyone was getting the point of Oil, so I resolved to write an “elevator pitch” for it [2]. (Although I think most people on Lobsters get it, since the audience is more sophisticated.)

    I haven’t published that post yet, but the pitch is: Oil is the language you can convert bash scripts to automatically, once they become a maintenance problem

    That might happen at 50 lines for some people or 1000 lines for other people.

    My claim is that, in general, X isn’t a good bash replacement, where X is Python/Ruby/Perl/JavaScript. I think that’s obvious to some people but not to others (typically Python programmers who don’t know shell, which was me in the not-too-distant past).

    There are certainly cases where porting from bash to Python is a good idea.

    But I also had the revelation of porting Python to shell, and being relieved (e.g. more than one deployment script). I was a Python person and I came at it from the opposite side. Shell is really expressive, but it’s hampered horrible syntax and a bad/old implementation.

    In summary, the conundrum of porting things back and forth between bash <=> Python/Ruby/Perl/JavaScript is why Oil exists. It seems like this debate will never end, and I hope that the “automatic conversion” property [3] is a unique argument in favor of Oil vs. X.

    If anyone is skeptical of my elevator pitch I’m interested in the feedback :)

    [1] http://www.oilshell.org/

    [2] http://www.oilshell.org/blog/2017/07/31.html

    [3] http://www.oilshell.org/blog/2017/02/05.html

    1. 6

      Python is also larger than bash by most measures and cannot as easily make use of the existing Unix toolchain. A better selection that combines both shell-like scripting with consistent syntax and the ability to much more easily integrate itself into the Unix ecosystem is good old Tcl by way of tclsh.

      1. 3

        Here are some concerns: The syntax can be obscure.

        Nonissue.

        It’s slow. While the speed of a shell script rarely matters, trying to use the shell like a programming language will waste system resources.

        When speed matters, python is not going to be helpful.

        We can often omit crucial features of a script. Checking the status of programs using $? can be accidentally left off, leading to inconsistent behavior.

        Just like all other languages.

        The shell language’s only data structure is the string. There are ways of decomposing strings into words. The expr program can convert strings to numbers to do arithmetic. The date program allows some date manipulations, but the rules can be obscure.

        Not even wrong.

        array=(a b c)
        ((x+=y))
        

        obscure : the second appearance of the word in the sentences I quoted here. Let’s do s/obscure/unknown to the author/.

        Unit testing isn’t easy. There are some packages like Bats that can help with unit testing. A language like Python has a much more robust unit testing capability.

        I totally agree.

        1. 6

          Just like all other languages.

          No, other languages have e.g. types.

          Nonissue.

          Of course syntax can be an issue. Shell scripts that are written by humans should be readable by humans.

          1. 3

            shell scripts are, for the most part readable by humans. Even before I could write a shell script without cribbing off an existing one, I could understand what they were doing 90+% of the time.

            But I would also say that if your job is ops-heavy, you should probably know how to read and write bash. Not because you’ll be writing all your scripts in shell, but because you’re working in a field where a large number of small utilities that you can basically just grab and use are written in shell already.

            I wholeheartedly agree with the author that for larger tools should be written in a higher level language almost all the time, but an ops-person should be mostly fluent with shell syntax, and the shell is more easily read than java, c#, and other languages people use every day.

        2. 3

          I actually moved a small Python script to bash the other day because of the ease and familiarity I have with the CLI tools versus the modules in Python. I found the script wasn’t really suited for python anyways:

          1. Git clone from our Magento repository
          2. If given, checkout branch
          3. Copy localized configuration (pre-built files for prod, staging, qa, etc) into application
          4. Run a gulp build that compiles SASS, minifies CSS/JS, etc
          5. tar the whole application, leaving out unnecessary files for production (.git, node_modules, gulpfile.js, etc)

          Now we have an artifact to release!

          1. 1

            The module sh is a fantastic tool for these kind of scripts. https://github.com/amoffat/sh