Bashing the Bash – Replacing Shell Scripts with Python
1–10 of 45 posts
Re: Bashing the Bash – Replacing Shell Scripts with Python
#2I think Bash is much more than that. For example, I mostly compose chains of commands through pipes. This extension is not pipe-centric.
Re: Bashing the Bash – Replacing Shell Scripts with Python
#3I think Bash is much more than that. For example, I mostly compose chains of commands through pipes. This extension is not pipe-centric.
This so much. Using grep, cat, cut and sed to parse log files (in my case output from quantum chemical calculations) is really nice.
Re: Bashing the Bash – Replacing Shell Scripts with Python
#4This reminds me of the Google guidelines[1] for when to use Bash.
Between Python's extensive standard library and the ability to call shell commands[2] if necessary, I rarely reach for Bash.
[1]: https://google.github.io/styleguide/shell.xml?showone=When_t...
[2]: https://stackoverflow.com/questions/89228/calling-an-externa...
Re: Bashing the Bash – Replacing Shell Scripts with Python
#5I think the author forgets to mention that the primary reason bash is used is because of its cross distribution support.
I known if i write my script in bash it will work on any small linux distro.
I think python is a close second, but it still use bash to bootstrap my environment for my real work.
Re: Bashing the Bash – Replacing Shell Scripts with Python
#6I like the idea, but that Python code doesn't look like "without much real work." The bash script is so much shorter.
Re: Bashing the Bash – Replacing Shell Scripts with Python
#7The 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 port from shell to Python. But to me it only succeeds in proving the opposite point -- that porting to Python is a lot of effort, and the result has a lot of detail that doesn't match the problem domain. Error handling is possible, which is good, but awkward. And now you need external librariesl like psutil, then a package manager and special deployment tools for Python. (And you probably need some shell scripts to build/deploy your Python...)
One thing I don't see is the complete result, which from the looks of it is pretty clunky compared to the 20 or so lines of bash.
-----
About Oil: I realized that not everyone was getting the point of it, so I resolved to write an “elevator pitch” [2].
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.
Oil will have a more uniform syntax [6], not 4 different sublanguages [3]. It will get rid of word splitting, and have proper arrays [4] and hash tables. It should be easy to write a test framework in it, as opposed to bash test frameworks like bats [5] which actually modify/extend the language because it's not powerful enough.
There are some 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 [6] is a unique argument in favor of Oil vs. X.
If anyone is skeptical of my elevator pitch I’m interested in the feedback :) You can also try the first release [7].
[2] http://www.oilshell.org/blog/2017/07/31.html
[3] http://www.oilshell.org/blog/2016/10/26.html
[4] http://www.oilshell.org/blog/2016/11/06.html
[5] https://github.com/sstephenson/bats
Re: Bashing the Bash – Replacing Shell Scripts with Python
#8I love both bash and python. I almost always write the first version of a script in bash, especially if it involves piping between commands, managing processes, or moving files around the file system. Only when there is significant parsing involved do I reach for python -- and even then, it's often easier to just use python for the bit of parsing that's necessary, within a heredoc using python -c.
The example script in this article hardly made use of pipes. I think if you tried to convert a shell script that used a lot of piping, the python might not come out so elegantly.
As others have mentioned, bash, or at the very least shell, also has more cross platform support (certainly more than python3). Even on resource constrained or embedded systems, you're likely to have access to a shell, whereas python is not guaranteed to be installed.
Both are good tools, and both excel in different ways; but I'm not prepared to throw out the baby with the bathwater and say bash is useless, always use python.
Re: Bashing the Bash – Replacing Shell Scripts with Python
#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, you have to use a module, read its documentation, and be prepared to write ugly, verbose method calls all around.
Re: Bashing the Bash – Replacing Shell Scripts with Python
#10The 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 readability of the program is key as well. It's interesting that the author never included the full Python program. Based on the snippets I would expect it was longer and was definitely far more verbose. One of Bash's advantages in terms of working with files and shell commands is that most people already know how to work with files and shell commands at the command prompt and so the clarity is already there. If you replace all that with Python library calls all the sudden you're speaking a different language and comprehension will be slower unless your reader works with those Python libs just as often as they use the command line.
In other words, this may all sound good but be careful with this sort of advice. It's often counterproductive to go down this particular path