OSNews

While I agree that Python is not a replacement for the shell, your post show the shell's problem: first there is not one shell, but several and the 'script shells' depends on a bunch of tools, all of which have variants depending on the version, OS, etc.

Most script shells are *brittle*, use them on another shell, OS, on file with spaces or weird characters and they break.

What I would like to see is a bunch of tools written in Ruby/Python which would send struct/hash through the pipe: you would have the flexibility of shell and the robustness induced by passing structures/hash around instead of 'hard to parse' text (and if you have to take into account files with weird characters in them, it's really not so easy).

That was pretty much the motivation for creating Perl back in the 80s. The situation has improved quite a lot since then. The end of the Unix wars brought a good deal of industry consolidation and the standardization of all those tools. Nowadays it's quite feasible to create shell scripts devoid of this kind of problems.

Even the shell is standardized. POSIX 1003.2 made /bin/sh a KornShell lookalike rather than the historical Bourne shell. That's the only shell you should use for scripts.

But the one true reason to prefer shell scripts is that way you can leverage your knowledge of the command line. Conversely, writing shell scripts will improve your skills in all the standard Unix utilities. Once you start using Perl, Python, etc. you'll have to learn two ways of doing the same thing: One way to do it interactively and one to script it.

Using bash/ksh/nawk/grep etc. is fine for some things. And of course, that's where it should be used.

We have a guy at work who has pretty much the same attitude as you and he insists on doing EVERYTHING in ksh/nawk. He wrote things like XML parsers in nawk (not fully functional, of course, but they almost work for what he needs it for)

In the end, he manages to create slow, error-
prone incomprehensible stuff that would have been fairly simple, fast and easier to make correct in for example python.

So hold on to your bash, but just don't take it too far.

Heh, reminds me of a place I used to work. Their reporting system was kinda like this:

* The server gets a request for report X.
* Server grabs list of environment variables for report X from the DB
* Server sets the environment variables with values passed in the request.
* Server spawns ksh with the appropriate reporting script.
* Shell script uses IO redirection to send SQL to Oracle
* Shell script parses the data and stores it to a temp file.
* The server reads the temp file and sends it back to the client.

The great part is, the guy who actually "designed" that part, left for some other job and nobody else there knew Korn shell.

I think that's exactly what the articles suggests. There's no implying that Python should replace Bash, but complement it for those scripts that are too much for Bash. If anything, it attempts to replace Perl, not Bash.

The great thing about using shell scripts to their maximum capacity is that there are no modules. With perl and python, the suggestion for common use involves a module, which may or may _not_ be on the system.

You will find that once you go down the path of attempting to install a module for an interpreted language, your systems can become out of sync with one another. Not so with shell scripts. A Bourne shell function works as well on one system as it certainly will another.

Even when programming to capture missing modules, have you found that exception use of import (python) or require (perl) involves a lot of alarm bells and whistles. And you do this so that you catch the exception to be able to begin the installation of the module dependencies and module rather than actually getting on with better things to do?