When it comes to talk about scripting, we cannot avoid talking about the probably most famous of the shells: the Bourne Again SHell. Thoroughly explaining it would require a whole book, so as usual in this post we explore only the features that it’s theory likely the reader should learn. The post is not intended to be easily understood by new-bies: it is structured as a cheat sheet, so the reader can use it as a quick reference when needed, but this approach has the drawback that there’s not much room to elaborate things enough.
Category: Scripting
I sometimes heard claims such as “shell scripting is no more necessary since now we have Python“, or “I don’t like Python, I can do everything with shell scripts“.
Both of the above claims are too simplistic: skilled professionals that know both of them for true know also that they both have pros and cons. So the right approach probably is to use the one that best fit the use case in terms of delivery time and maintainability.
For example:
- if the use case is housekeeping of files and directories, or automating tasks that run a lot of shell commands, a shell script certainly wins over a Python script in terms of delivery time
- when it comes to data search and manipulation, in simplest use cases may be still convenient to use shell scripting, but when complex formats such as JSON, XML or YAML are involved, it is certainly more effective to develop using Python
- the same applies when developing scripts that connect to REST API: it is straightforward that Python is the best choice
So, to keep it short, professionals should know both shell scripting as well as Python, so to pick the right one for the particular use case they are working onto.
This is the first of a set of three posts aimed at showing how to create a full featured Python3 project: since the topic is quite massive, I decided to split it into three different posts. In this post we do not only quickly see how to develop a full featured Python application, since I wanted to do something that shows a lot of things, such as:
- creating Python objects
- put the custom Python objects inside a Python package within the scope of our own namespace
- develop accordingly to encapsulation rules, by implementing getters and setters methods that look like regular attributes by exploiting decorators
- use the standard Python logging facility, configuring everything with an external settings file
- altering the __eq__ comparison so to consider two objects as equal when one of their attribute has the same value
- implementing comparison methods and the __iter__ method, so to be able to use Python standard functions such as sorted() to sort it also in reverse order
- exploit total_ordering to make an object fully sortable
The next parts of this post will be on the following topics
- the second one is about delivering the object as a Python package
- the third and last post Packaging a Python Wheel as RPM is about how to pack this project into two RPM packages, also seeing how to digitally sign these RPM packages, and in general how to set up an RPM development environment, with a good overview on how to exploit the RPM building tools