Comment by arendtio

5 years ago

Actually, I wonder why not every OS comes with a Posix shell and an Python interpreter nowadays. Posix shells should be super easy, because most systems have them onboard already anyways. However, since Posix shells are kinda broken, I think Python should be the next iteration.

Just to give some context, I am not a Python person, as I prefer Go. But given the popularity and the suited use-cases I think it is a good option.

The problem is bash et al are languages designed for the command line. Every line is a separate command.

Contrast:

    cat test.txt | grep search

With:[0]

    import os
    import subprocess
    with open('test.txt', 'r') as f:
        for line in f:
            line = line.rstrip()
            subprocess.call(['/bin/grep', line, 'search'])

While the first may use some “magic” symbols such as the pipe, it’s really concise in conveying what it’s doing.

I will give you this: bash variables and expansions can be confusing. Contrast with programming where this probably works:

    "start" + variable + "end"

[0]: https://stackoverflow.com/a/9018183/1350209

  • My problem with shells is not just about the obscure syntax, but rather about the point, that it is next to impossible to write reliable and reusable scripts.

    By default return codes of failed commands are silently ignored and `set -e` does not work under all circumstances. By default every variable is part of the global scope and the best you can do about it in a POSIX compliant way are sub-shells, which in turn have no way to change variables outside of their scope.

    It is just broken by design :-/

    • It's because shells are really designed as ways to run and manage tasks (subprocesses). So anything not related to that is at best secondary, and a pain in the ass.

      The opposite being true for your average general-purpose program, where managing tasks is a secondary concern and delegated to a library.

  • Not only is the intent of those snippets rather different, you've rather misunderstood the original to the extent that it's broken.

    The bash version looks for the pattern `search` in every line of `test.txt`, the Python version treats `test.txt` as a file of patterns, and look for each of these patterns in the file `search`.

    And of course you wouldn't implement the bash version in python that way as it's rather trivial to do it in Python:

        out = [line for line in open('test.txt') if 'search' in line]
    

    or somesuch.

As somewhat of a Python developer these days, I have to point out that each 3.something release of Python potentially breaks backwards compatibility.

Second issue is that Python without any extra modules is still pretty limited, nearly every serious python project comes with some extra dependencies.

So have a Python interpreter available only gets you so far...

(For the record, the same could be said about pretty much all dynamic languages I'm familiar with).

Maybe a POSIX shell, as the POSIX shell standard is small and more most purposes fixed. But you don't want to use the OS python, as it is inevitably old and outdated.