Confused with doing sys admin things with python or not

I was doing backups in bash and I have written few other bash scripts as well. I wanted to shift it to python because I needed to learn python for AI techniques and I was always delaying that. As I have to do sys admin things very often, so I thought if I do things in python then it will make good at python. Now I am confused with few things

1)I have seen that I can do things in 1 line in bash but in python I need to write 15 lines of code for that .e,g making the tar ball backups. sed, awk can filter files in line where in python I have to write many more lines. So my questions am I going on wrong path. Is python really used for sys admin things or not. For me its like making a 5 pages static website in J2EE rather in plain html.

2)I want to know how why should person choose python if bash can do everything. I am only talking bout sys admin things.

So I need to know am I over killing myself by trying to use python or is it just because I'm still learning that I'm finding it difficult?

I just want to know whether python really meant for those things like backups, checking log files etc.

Solution 1:

Python is a general-purpose scripting language like Perl is. That means it is more powerful tool than bash scripting, but it also means that the syntax is generally going to be more verbose and writing scripts will be more complicated. Bash scripts have the advantage of being domain-specific, and that means they make a lot of assumptions that make most tasks easier. However, if the assumptions bash has made don't fit the task you need to do, you might have to go the long way around to make things work the way you need them to.

This is the same question Windows sysadmins used to face when dealing with writing in batch or VBScript. PowerShell helps alleviate that quite a bit, but you still face the issue of "is this task complex enough to require PowerShell, or is a batch script good enough to get the job done reliably?".

In reality, it does depend on the task you need to do. If a task is more easy for you to write and maintain in Python, use that. If bash is actually really simple, use that. Scripting languages are tools. Use them as such. Use the tool which best suits the requirements of your task.

When I'm writing a script, I have a mental checklist:

1. What exactly is the task I'm trying to accomplish? Step one is always define the problem.
2. Which language is faster for me to write this script in? My time is valuable.
3. Which language is better for someone else to read, understand, and support for this task? Other people's time is valuable, too.
4. Which language is going to result in the more robust, more reliable, or more long-term fix? I want to write this once and have it fixed forever.
5. Is there anything which makes a language inappropriate? Will Python or PowerShell not be available, or will certain modules not be installed? Will my batch file or bash script call programs which are not guaranteed to be present and that I can't maintain with the script?

Solution 2:

You're asking a somewhat rhetorical question here. It's like asking why would someone have different socket sets in their tool box when one socket set would work. Each tool (in this case program/language/scripting environment) has it's own unique strengths and weaknesses. For example why would you use Puppet (Written in Ruby) when CFEngine (Written in C I believe) does the same thing?

One of the biggest advantages of a scripting language over a shell environment is readability (obfuscated Perl not withstanding). It can also be a lot easier to do in language string manipulation. In Bash for instance you may need to echo your string to sed/awk/grep to parse it, but in Python/Ruby/Perl you have regex and string manipulation built in. Also communication with remote sockets might be easier than having to write a script around curl, wget or netcat. Also scripting languages don't need to fork to do their processing. Example:

myvar=$(echo "my string" | grep string | cut -d"" -f 3)

That would result in the creation of three separate forks which in turn slow down the system.

Bottom line Python was designed to fill a need, and due to that it has it's strengths and weaknesses. The difference between a great sys-admin and a mediocre sys-admin is they know the strengths of the various tools. Learning Python is a good idea, but it's not the one size fits all tool.

Solution 3:

I am a sysadmin and a python programmer. What I usually do is to think ahead and weight what I will have to do to achieve something in bash and in python, and then using the best tool to the job (the one that gives me more speed/power). One doesn't exclude the other, take a look at the python os module and you will see that there are many things there that can help in system administration.

As a rule of thumb (that I use, YMMV): if you will have to run a lot of commands you will be better with bash, and if you will have to do formatting and calculations from text files python will be better.

Also, you say you are learning python so I suggest you to stick to what you know best first. Get some test projects rolling to get intimacy with python and when you get better at it you will see that you will naturally tend to do things in bash or python according to the complexity of what you want to do.

Solution 4:

As a sysadmin that uses python and bash frequently, I can say that I often have the same question you do. Generally (very generally) I seriously reconsider using python for sysadmin stuff when I realize I will need multiple open() commands or need to import subprocess (or similar) if I implement it in python. That said, sometimes python is easier for you to add extra functionality later. On many occasions I have written something I thought was simple in bash, then reworked it in python (or whatever programming language) because I realized it was much more complex than I thought.

Really it is up to you as the programmer to decide. Don't rule out one method if you don't know how though -- if you can learn from the experience, why wouldn't you?