I know what Python is. Not that I've used it extensively, but I want to. I have only written a test program to put some old DOS program of myself into GTK(2).
But that isn't what I was asking. Perhaps my question was a little disingenuitive. I cannot really see how Python scripts are easier to modify and distribute. For one, it is a more extensive language by far and for that reason the wish or desire or opportunity for learning it "by chance" or "as you go" as it were is a lot slimmer.
I'm just saying the number of people willing to learn Python to make a few scripts in the shell is a lot smaller than those willing to mess about with Bash for a while. I am saying that because "man bash" is enough to get a good bearing on what to do and you can just observe existing scripts and they don't require a python interpreter, nor do you have to deal with version issues (2 > 3). The madness surrounding the move to Python 3 is incredible. I have had to print on paper the various features that a certain migration library provided. It is not here and I am not sure exactly anymore what is was. I think it was something to enable access to 3 features to 2 programs. Because personally I intend to develop for version 2 still and not go with version 3.
Python 3, I must and may say, is one of those advances that the community or the world in general (the programmers) find a hard time accepting. And then those people pushing it, really start pushing it. "There is no reason to stick to 2." But if half the world sticks to 2, apparently there is a very good reason for it. All the same, there is also SQlite version 2 that is still very much around. For reasons probably that version 3 introduced complexity and made the (binary) format more complex, things to do with UTF8 also.
Python is ubiquitous, that's true. There are even a few dozen python packages for my Synology NAS. That "few dozen" is actually 175 packages that have "python" in the name excluding one thing that just mentioned that it was written in it.
And it may be the most elegant language I have ever seen. Not that the GTK coding proved to be that easy, but that aside. But there is also silliness. I don't remember. There not being any for loop? I guess, and that's the point of all of this, there is a tool for everything. I just think that Python is not suited for Bash scripts or the style of regular shell scripts because:
- the scope of the language is much larger; you don't necessarily use the GNU tools that are available in a unix system, as such it is less modular from that point of view, these are tools you may want to use anyhow. It is, to my light, essential that you learn how to use find, grep, and many other commands. Shell scripts can be created on the command prompt, and they are required for bash configuration files. Being dependent on another interpreter is not a good thing and may cause problems when you need to work on smaller or even embedded systems.
- the program you created in Python is like one of the base unix utilities that I just mentioned.
- writing Python puts you into the mood of writing a "real program" instead of a script. It is a bit of a longer thing and you may want to push your goals higher when doing so, thereby requiring more dedication at least from my point of view. Personally I always try to make do with least amount of effort required to have fun. Doing stuff in advance of something else is something I don't like. I just go ahead and work my way through the madness and the mazes.
- I personally want to use Python to write a (cronned) (or something) website backend, like a data mining thing or store. I also want it to interface with PHP. I also want to use it to write a Java server application and have Python as a scripting engine that gets linked directly as a form of library inclusion (so not using the command line program, but just a python lib that executes the interpreter and an API that I can use from Java).
- even though Bash is really terse (you should see the style I have developed now) with many commands on a single line, this is actually an advantage from a scripting (shell scripting) POV. Since the constructs bash uses are always the same (apart from really far-off constructs the way you can see them in "configure" scripts, those are really advanced. Unreadable. But the regular style that I am using is always the same, so it is not even that hard to read as soon as you are accustomed to it.
- the advantages you mentioned are not advantages for a shell script. Enforced indentation is something I do for myself when I have the time or desire to make it pretty. Multiple execute statements on a single line does not happen all that easily in Bash because your lines in a terminal window are just not that long. As a programmer you usually stick to lines of 80 or 100 or 120 characters anyway. It is very easy in Bash to break lines and indent. The style I have now makes for very easy branching and if you stick to a certain format you won't make all that many mistakes, although there is still in this current style of mine a risk to mis-assess what the thing is going to do on this planet of earth and beyond
.
I like playing with fire now and then
.
I am really doing weird stuff in Bash out of my desire not to use all that much exit statements and the like.
My apologies for not posting this message earlier. I guess I was not done. So people responded before I did. Well, whatever.
But that isn't what I was asking. Perhaps my question was a little disingenuitive. I cannot really see how Python scripts are easier to modify and distribute. For one, it is a more extensive language by far and for that reason the wish or desire or opportunity for learning it "by chance" or "as you go" as it were is a lot slimmer.
I'm just saying the number of people willing to learn Python to make a few scripts in the shell is a lot smaller than those willing to mess about with Bash for a while. I am saying that because "man bash" is enough to get a good bearing on what to do and you can just observe existing scripts and they don't require a python interpreter, nor do you have to deal with version issues (2 > 3). The madness surrounding the move to Python 3 is incredible. I have had to print on paper the various features that a certain migration library provided. It is not here and I am not sure exactly anymore what is was. I think it was something to enable access to 3 features to 2 programs. Because personally I intend to develop for version 2 still and not go with version 3.
Python 3, I must and may say, is one of those advances that the community or the world in general (the programmers) find a hard time accepting. And then those people pushing it, really start pushing it. "There is no reason to stick to 2." But if half the world sticks to 2, apparently there is a very good reason for it. All the same, there is also SQlite version 2 that is still very much around. For reasons probably that version 3 introduced complexity and made the (binary) format more complex, things to do with UTF8 also.
Python is ubiquitous, that's true. There are even a few dozen python packages for my Synology NAS. That "few dozen" is actually 175 packages that have "python" in the name excluding one thing that just mentioned that it was written in it.
And it may be the most elegant language I have ever seen. Not that the GTK coding proved to be that easy, but that aside. But there is also silliness. I don't remember. There not being any for loop? I guess, and that's the point of all of this, there is a tool for everything. I just think that Python is not suited for Bash scripts or the style of regular shell scripts because:
- the scope of the language is much larger; you don't necessarily use the GNU tools that are available in a unix system, as such it is less modular from that point of view, these are tools you may want to use anyhow. It is, to my light, essential that you learn how to use find, grep, and many other commands. Shell scripts can be created on the command prompt, and they are required for bash configuration files. Being dependent on another interpreter is not a good thing and may cause problems when you need to work on smaller or even embedded systems.
- the program you created in Python is like one of the base unix utilities that I just mentioned.
- writing Python puts you into the mood of writing a "real program" instead of a script. It is a bit of a longer thing and you may want to push your goals higher when doing so, thereby requiring more dedication at least from my point of view. Personally I always try to make do with least amount of effort required to have fun. Doing stuff in advance of something else is something I don't like. I just go ahead and work my way through the madness and the mazes.
- I personally want to use Python to write a (cronned) (or something) website backend, like a data mining thing or store. I also want it to interface with PHP. I also want to use it to write a Java server application and have Python as a scripting engine that gets linked directly as a form of library inclusion (so not using the command line program, but just a python lib that executes the interpreter and an API that I can use from Java).
- even though Bash is really terse (you should see the style I have developed now) with many commands on a single line, this is actually an advantage from a scripting (shell scripting) POV. Since the constructs bash uses are always the same (apart from really far-off constructs the way you can see them in "configure" scripts, those are really advanced. Unreadable. But the regular style that I am using is always the same, so it is not even that hard to read as soon as you are accustomed to it.
- the advantages you mentioned are not advantages for a shell script. Enforced indentation is something I do for myself when I have the time or desire to make it pretty. Multiple execute statements on a single line does not happen all that easily in Bash because your lines in a terminal window are just not that long. As a programmer you usually stick to lines of 80 or 100 or 120 characters anyway. It is very easy in Bash to break lines and indent. The style I have now makes for very easy branching and if you stick to a certain format you won't make all that many mistakes, although there is still in this current style of mine a risk to mis-assess what the thing is going to do on this planet of earth and beyond
.I like playing with fire now and then
.I am really doing weird stuff in Bash out of my desire not to use all that much exit statements and the like.
My apologies for not posting this message earlier. I guess I was not done. So people responded before I did. Well, whatever.
Comment