I'm a Python programmer that prefers to develop on Windows but still end up deploying to a Linux server.

I've just finished writing a little script: stuff that downloads files from a site, generates a sitemap, gzip it, pings the search engines and emails the response code.

Nowadays most GNU tools are available and compiled also for Windows and I sure do use Wget and Grep whenever I need to.

Until now I've always tried to implement the functionality I needed in Python (gzipping and opening urls require very few lines of code) but I found myself thinking if maybe I could write more resilient code if I didn't reinvent the wheel and just scripted everything in a bash script style where a big part of the functionality is delegated to an external process such as mail, wget, curl, etc and the other tools *nix makes generally available.

What is your take on this? When you target *nix do you glue tools together or you tend to implement all the functionality in your scripting language of choice?

3 Answers 3


Depends on your intended audience.

If this is a general app then you may need to bundle these tools with it, make sure that they still work with changes and updates to windows and make sure they don't clash with any windows built-ins. Git has to do this on Windows, it bundles a lot of the mingw tools

If the app is aimed at non-techncial users this may be easier since you can stick the tools in a local sub directory and not have to worry about them clashing with other cygwin/mingw/etc tools.

You should also be aware of security warnings, if a user runs your app and gets a message about wget (which they have never heard of) trying to breach the firewall they may get nervous!


If you want to write a small script, well for god's sake write a small script. If you want to write a program (even if part of that program uses external programs), write a program. If you have a well-defined target platform, feel free to use its capabilities either way. And yes, reinventhing the wheel is bad either way (but you seem to have an overly libral definition of that term, see below).

That particular .py file is basically doing the same thing as a bunch of wget and tar calls? You'd bet hell will freeze over before the file is used on a non-unix server? Then write it like a shell script (or if your logic is simple enough, just write a shell script!). Things like that are simple enough to rewrite in the unlikely case they need to be made really portable; but until then, YAGNI.

Things are different for library code and general-purpose applications. If you can do it without adding a dependency on an external program, then do it. Every time you do that, you add portability and ease deployment (GNU coreutils may be available on windows, but who's going to package it for inclusion in your app? Or, worse, tell users to download these fifty programs?). And every ounce of that is sacred, it may save someone's day in the future (it may be yourself, someone else working on your project, or even the proverbial violent psychopath who knows where you live). Gluing together standard library modules in a few lines is not wheel reinvention. Rewriting the whole module is wheel reinvention. But even that may be acceptable as a necessary evil if the wheel you're reinventing only works natively on two platform, runs only through cygwin on a third and doesn't work at all on the fourth... but that's another topic, a topic that has been covered extensively in the past and will be debated even more in the future.


When you target *nix do you glue tools together or you tend to implement all the functionality in your scripting language of choice?

Note that most scripting languages are good at interacting with other programs, so when I use them instead of sh or bash, it is seldom for "implementing all functionality" myself.

The decision point I have found is, how much arithmetics or data structures is needed. Often a shell-script is fine. At other times a perl- or python-program is better.

In bash there are array variables, string operations, and integer arithmetics, but any non-trivial use of these tend to be awkward and produce ugly code.

A plus with the Bourne Shell family, is the very useful case-esac construct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.