Live data from Hacker News

Bashing the Bash – Replacing Shell Scripts with Python

medium.com

21–30 of 45 posts

Re: Bashing the Bash – Replacing Shell Scripts with Python

#21
A while ago I wrote a tiny language (called bish) that was an attempt at finding a middle ground for this problem. Essentially, you write your shell scripts in bish, with sane syntax and semantics (example: function return values, which are not really present in bash). The bish compiler then compiles your script to bash.

I haven't touched it in a few years now, but maybe it's of interest to someone: https://github.com/tdenniston/bish

Re: Bashing the Bash – Replacing Shell Scripts with Python

#22
post #16
post #9

> I’ve idealized the four steps as separate functions. Does the author know he can write functions in bash? I mean, if he wants to compare programming languages, he should at least compare similar programming styles. Bash is great for OS scripts because it has built-in commands and syntax for dealing with processus and their inter-communication (pipes and stuff). Python has NOTHING about that. If you want to do this,…

The problem with Bash functions is that they aren't really functions -- more like subroutines. You can't even return a value from a Bash function (just a numeric status code). Most of the functions the author wrote wouldn't even be possible in Bash, if only because they utilize return values. So your suggestion that he "compare similar programming styles" is practically impossible without using implicit state-passing…

> You can't even return a value from a Bash function (just a numeric status code).

You can print a textual result and store it in a variable, which is a pretty natural pattern in bash, e.g.,

    set -e
   
    download_command () {
        if type wget >/dev/null 2>&1; then
            echo "wget -q -O-"
        elif type curl >/dev/null 2>&1; then
            echo "curl -sL"
        else
            echo "Error: curl or wget is required" >&2
            exit 1
        fi
    }

    download=$(download_command)
    public_v4=$($download http://whatismyip.akamai.com/)
    public_v6=$($download http://ipv6.whatismyip.akamai.com/)
The numeric status code is best used to indicate errors (as above, with set -e), not to overload for data.

I do agree that I'd prefer being able to return actual structured data and not strings -- but honestly you can pass e.g. JSON back-and-forth between commands that take JSON, and into `python -c 'import sys, json; something(json.loads(sys.stdin))'` if you need it for a small part of a script that's generally better written in sh.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#24
post #16
post #9

> I’ve idealized the four steps as separate functions. Does the author know he can write functions in bash? I mean, if he wants to compare programming languages, he should at least compare similar programming styles. Bash is great for OS scripts because it has built-in commands and syntax for dealing with processus and their inter-communication (pipes and stuff). Python has NOTHING about that. If you want to do this,…

The problem with Bash functions is that they aren't really functions -- more like subroutines. You can't even return a value from a Bash function (just a numeric status code). Most of the functions the author wrote wouldn't even be possible in Bash, if only because they utilize return values. So your suggestion that he "compare similar programming styles" is practically impossible without using implicit state-passing…

Return-values in (ba)sh is text output. You can pipe to and from a function in bash, and you can use replacement [eg: host=$(hostname)].

It's different, but it's a powerful paradigm.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#25
post #23

Unit testing just means running your programs or subprograms with different inputs and checking the result. Nothing about this is hard in bash. Why would it be?

This is usually referred to as functional or acceptance testing. The goal of these types of tests is to confirm that the overall application works as expected from a users perspective. This is easy with bash. Testing individual units of code inside of a bash script is more difficult. This can be useful for pin pointing which function introduced a bug.

Edit: want to add that difficult does not mean impossible. Bats exists, and you could structure a bash script to be more easily testable.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#26
post #23

Unit testing just means running your programs or subprograms with different inputs and checking the result. Nothing about this is hard in bash. Why would it be?

This is usually referred to as functional or acceptance testing. The goal of these types of tests is to confirm that the overall application works as expected from a users perspective. This is easy with bash. Testing individual units of code inside of a bash script is more difficult. This can be useful for pin pointing which function introduced a bug. Edit: want to add that difficult does not mean impossible. Bats ex…

Yeah, I just don't understand what actually makes it difficult.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#27
The thing other languages lack for me is a clean way to execute other programs. With bash it's just "grep whatever", in other languages it's "exec('grep whatever');". Then piping that output to another program is a lot of work.

Bash makes for really good program glue.

I've considered creating a library that scanned your PATH for binaries then created dynamic function signatures to allow calling the function by name. Then that dynamic module can be included, and you'll be able to grep by calling "grep". You could make it chainable and get something like: grep('something').cut('args'); or whatever.

Of course this would only be used for personal utility scripts.

Re: Bashing the Bash – Replacing Shell Scripts with Python

#29
post #13
post #7

The point of my shell project Oil ( http://www.oilshell.org/blog/ ) is to get rid of the shell vs. Python debate. 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 X programmers who don’t know shell, which was me in the not-too-distant past). This article is good because it has a port of a realistic…

There is no [2] in your list of links. Does it refer to to the elevator pitch you included in your post, or did you intend to link somewhere?

Thanks I fixed it -- there is no real link #1 but I got lazy and didn't renumber all the links.

In that post I promised an elevator pitch, but didn't write it yet. I just wrote it in that comment:

Oil is the language you can automatically convert bash scripts to.

It's exactly what everybody in this thread is debating. I think the debate won't end because both bash and Python have deficiencies for a very common set of tasks. I guess this set of tasks got more important with cloud and containers and whatnot.

Feedback appreciated :)

Re: Bashing the Bash – Replacing Shell Scripts with Python

#30

The key is knowing what to use where. Writing certain scripts in Bash is miles more efficient use of time than using python because it's "better". While it's certainly possible to write bad scripts in Bash like the example given, it's just as possible to write bad scripts in Python. All the time spent learning to do bash-like stuff in Python could just as well be spent learning to write better Bash. I think the reada…

I completely agree. It really depends on how mission critical the script is. One huge advantage with writing it in another language is the ability to write tests for the script.
Post reply on HN