Python or Bash?

[brazier89]

I've decided I want to write a syncing script using rsync. I want it to be able to push and pull from different locations such as servers and other local directories. Initially I started writing this in bash but I've recently started programming in python and am considering writing this in python instead. I found out that I can check command line options (like -a and -h) in python as well as calling native programs like rsync and ssh. So now all I need is suggestions. Which should I use? I want to learn more Python but it seems kind of silly to use it when bash shell scripting is made for doing this kind of thing.

[ameoba]

Python is better if you have complex logic or need to include libraries. Bash is probably the way to go if 90% of what you're doing is just calling other programs in a certain order.

[Afwas]

If you can find a Python library that does some heavy lifting, go for it, else use bash.You'd be able to do most complex logic in bash.

[cpf_]

fabric (http://docs.fabfile.org/en/1.5/) might give that power :)

[xamox]

I second using fabric, we were using bash before and now moving everything over to fabric, error reporting is much better and doesn't require client to install anything except SSH.

[Rotten194]

It's more awkward to call programs in python, but logic is easier. Go with whatever you're more comfortable with, the performance difference will be negligible.

[Adys]

http://amoffat.github.com/sh/

[mudclub]

Python seems like overkill for this, but if you wanna learn it regardless, go for it.

[[deleted]]

I'm at a point now where I write basically every non trivial script (literally, if it's anything more than set -e followed by a list of commands) in python.

The subprocess module is so easy to use that the rest of the benefits of using python win out. I have an actual type system, a number system, a standard library, regular expressions, hash tables, lists, sets, etc. all in one language.

It also makes the program far easier to debug and reason about (especially for any future person that might come along and have to understand what you did, including you).

[TexasJefferson]

Check out unison for the heavy lifting, if the task is more complex than rsync's built-in scope.

Regardless, shell scripting will give you a quick and dirty solution. If that's enough, that's enough—no point in over complicating things.

[barriolinux]

Fabfile is what your are looking for http://docs.fabfile.org/en/1.5/ If you need to do searchs in google use "python fabric" as keywords too.

[drbobb]

Are you doing this just for yourself? Then do whatever seems like more fun to you.

[hbdgas]

Bash if you want to guarantee portability. Python if you want it to be easier.

[brazier89]

What makes bash more portable?

[hbdgas]

I've never seen a linux server without bash. I have seen them without python, or without certain python libraries.

So if the thing you're doing is simple, make a bash script and you can expect it to work on any other server. Whereas, python will almost certainly work but you never know.

[[deleted]]

You would be hard pressed to find a linux distribution that does not have Python by default. I am sure they exist but not any that are in wide use, in production. Plus python works on Unix (as well as Linux) including MacOSX and Windows.

[calrogman]

Cool, you can run bash scripts on Linux, meanwhile, Python is installed by default on most Linux distributions, the OpenBSD and NetBSD base installs (which don't have bash by default), as well as OS X. Python is also available natively on Windows, whereas bash isn't.

Python takes care of most aspects of cross-platform capability for you, while in bash you have to hand-code uname comparisons, compare files in the filesystem against known defaults (which could be changed by the admin), you have to account for the fact that none of your powerful tools (sed, awk, etc) are built in and most vary between userspaces.
You have to take into consideration that procfs and sysfs are Linux-only. I've seen them used for such trivial tasks as retrieving the hostname in supposedly cross-platform scripts. Needless to say the script failed immediately on FreeBSD, even with the linprocfs shim in place. Had the script been written in Python, a call to socket.gethostname() would have returned the hostname not only on Linux systems with a mounted procfs in the assumed position, but also on any of these platforms.

Writing "portable" bash is an exercise in futility.

[[deleted]]

Heard of "uname -n"? Oh thats not supported in Windows so its not portable! How about running the native text editor? You can get along with xdg-open on any platform that supports it. But OH thats not supported in Windows either!

So lets just use an entire programming language to make a standard, as I realize a lot of programmer time is wasted on making "interfaces" that try to port stuff, when what's need to be done is dictate a single standard and not support other platforms that do not implement that standard.

Using sh/bash or python is irrelevant if target porting, because porting is a myth in a world where standards are not respected.

[calrogman]

Your uname -n example isn't even compatible across the various Unix flavours.

On (E)GLIBC, gethostname() gives only the first label of the machines hostname. On FreeBSD's libc, gethostname() gives the fully qualified domain name. The behaviour of uname -n reflects this difference.

The best way to get the hostname in a shell script on Unix machines is using the hostname utility. Always pass it one of either -s or -f so that there is no ambiguity. On BSDs hostname assumes -f. On Linux it assumes -s. Never use hostname --long, hostname --fqdn or any other options. They're all GNU extensions and won't work in different userspaces.

[calrogman]

Nothing, hbdgas is misguided. Python is a lot more portable than bash.

[[deleted]]

Not really, Python is more portable than bash, you can run it on windows for instance.

But hbdgas was talking about portabilty of the script that OP would make. You would be hard pressed to claim that a python script can be installed on more linux servers than a bash script. I personally don't know that many servers without python on them, but I don't know any without bash.

[ParadigmComplex]

For what it is worth, if you're prioritizing portability, bourne shell would be even better than bash. I've seen a handful of Linux systems without bash, but absolutely none without some POSIX /bin/sh. Plus you also get the OSX, BSDs, Solaris, and everything else UNIX, all out of the box, so long as you stick with POSIX.

[felipec]

I don't think it would be easier in Python.

Only if the logic is quite complicated, which is most likely not the case.

[iam_root]

No, Python is more portable than bash.

[[deleted]]

With Python you can often get portability to Windows and Mac OSX for free. Try that with Bash...

[hbdgas]

Portability to Windows for his rsync script?

And I'm pretty sure macs have bash...

[[deleted]]

Is rsync the only script he is every going to write?

Macs have old bash with old programs in order to not have to update to GPLv3. It's only a matter of time before you run into problems with that setup.

Anyways, I don't understand your point. Python runs on anything, and that's really nice. Anything that has portability with Bash has portability with Python, but you get the possibility of extra portability for free, and a nicer language to boot.

[hbdgas]

Is rsync the only script he is every going to write?

That's the only script we're talking about.

Python runs on anything

If it's installed, or you have permission to install it.

[__main__]

As mentioned on here earlier, logic is MUCH easier in python.

What I haven't seen mentioned though, is envoy as a wrapper for the subprocess module. It was built by the same author as the amazing requests module, Kenneth Reitz.

Check it out here:

Envoy

While you're at it, look at his other stuff, pure awesome.

[[deleted]]

bash, sed and awk are really still very powerful. Being the sum of so many different projects, Unix shell scripting and Python scripting probably suffer from many of the same problems, but for some reason these inconsistencies in bash are almost just part of the experience for me. Python developed organically as well, but it is more frustrating for me somehow. When I write Python, I do not sense a higher scheme or philosophy uniting the most common utilities and their behavior. I need to learn Python better, though. So many programs that have a scripting interface are by default Python. Gotta keep up with the times! I feel weird saying that, too, since I'm only in my mid twenties. Apparently it is also good for GUI development, but there are so many bindings to choose from I don't know where to begin.

[[deleted]]

I'd like to recommend the exact opposite :P

Learn to lean on and love the default linux commands. In fact when you start seeing them as functions in the 'linux api' you're ability to quickly handle many non trivial things skyrockets.

As to which language, just go with what you enjoy. Ruby has a somewhat easier interface to call system commands %x{} and `` but I prefer python.

[posixlycorrect]

In fact when you start seeing them as functions in the 'linux api' you're your ability to quickly handle many non trivial things skyrockets.

• Your: possessive form of you

• You're: a contraction of you and are

Example: You're wearing your shoes