I do not work in the programming area and I program by hobbie a bit in shell script, I wonder if it pays to deflower and become an advanced shell programmer ... I love shell!
Or
If I start to study another language !?

Remembering that I do not work in the programming area nor on servers ...

A usable shell allows you to easily manipulate and use the output of one command in another. Just like The Elders intended it to be. And basically its use is only limited by the way you can creatively (and efficiently) work around what it can't offer. (Especially if you need to learn to code true sh compatible code.) Once you find your creativity is limited by what a shell can offer you're ready to move on. And while there's fads and trends and all nice 'n shiny distractions any self-respecting UNIX admin knows (s)he's got to know a few PERL one-liners to be able to be get his or her CLI-fu going properly. One may like Python or Ruby but PERL remains the one language all UNIX systems offer by default.

3 members found this post helpful.

Personally I strongly advocate as soon as you find yourself reaching for a conditional or a loop..... Reach for a decent language like Ruby or D.


(Yes, you can run D in a scripting language like mode).


One thing shell does get right...

Learn to decompose your programs into lots of small processes.

What do you want to make your programs do? Shell scripts are great for certain tasks like working with files, but not very convenient for math, and no good at all for graphics. For these sorts of things, I would recommend Python, which by itself is fine for math and formulas, and with tkinter can do simple (two-dimensional) graphics.

You don't really go away from the shell. It strikes me as "the last mile" when it comes to programming.
That is, it's great for gluing together functionality really quick.

Take Lets Encrypt certbot. Using bash, you can glue in its renewal to quickly reload nginx if a new cert is issued in one line - very convenient!

In fact, when writing a python program (or general language you prefer), I try to make it along the unix philosophy of doing one single job well.
This way, parallelizing it is trivial and it makes integrating it with bash easy.
With python, using modules like argparse (for command line arguments), sys.argv and fileinput make things like cat myfile.csv | ./my_program.py -convertto json > myfile.json easy to do

If you are happy on the shell and do not need more functionality, I would not change.
I started looking at python when one of the applications that I ran offered a more extended interface for it.

I recently had a shell script in which I also needed to call python, so I converted it to python.

Also when dealing with more conditional stuff and more variables I would pick a more advanced language (for me python, but others suggest perl, ruby, d etc)

1 members found this post helpful.

What matters is what you wish to do, not what we recommend.

In another thread you asked a shell question, however it also asked a web application related question, and those two do not mix easily. Several people asked for further details, and your update there did not seem to clarify the original question.

If you love the shell. Then suggest you continue working with it. If at some point you wish to learn another language, no one will stop you and in fact many will offer you plenty of helpful advice.

More likely is that you try to do some personal projects using shell script but find that there are better ways if you used a different language. Probably the first few occurrences of this, you'll notice there were different options, but they won't deter you from continuing to use only shell programming.

As these occurrences add up, maybe at that possible, future point you'll decide you really do wish to start learning a different language.

2 members found this post helpful.

Programming languages are "the fundamental tools of your trade," such that you should always spend some time "studying a new one." You don't have to become an expert in it, but you should have seen it before, because surely one day you will see it again.

I happen to find the study enjoyable and very interesting. Languages, especially non-procedural ones such as gProlog, are fascinating to me ... and all are readily available on Linux. "If all you know so-far is PHP," say, you only have the faintest glimmer of what your computer can actually do for you.

Only Dr. Korn's shell contained a built-in scripting language that was seriously intended for programming. Instead, shells provide the so-called "#![i]shebang" facility which allows any external language to be used to define your "shell script."

IMHO, it is a complete waste of time to try to use Bash scripting to perform calisthenics – although I have certainly seen calisthenics being done! – when <<Perl | PHP | Ruby | Python | Java | JavaScript | JOVIAL | Haskell | WATFOR | pick_one>> could be used to do the job and is intended for the purpose.

All good advice. My own would be this. If you ARE looking to move to another language, a most important consideration is the available documentation. PERL wins hands-down on this. Both PERL and it's docn are probably already installed on your system: just enter 'man perl' and you'll already be on your way to learning the most versatile, powerful and comprehensive scripting language ever devised.

And remember to practise the Three PERL Virtues EVERY day: Laziness, Impatience, and Hubris!

1 members found this post helpful.

There are two main reasons to switch to another language (when you aren't forced to by some external requirement).

1) Computer languages are a bit like natural languages. Each one comes with a different set of assumptions and a different outlook on how problems should be solved. The more languages you know, the more problem solving approaches and points of view you will have. These can be applied in whatever language you are using at the moment.

2) When the languages you know either won't do what you want or just make it really hard.
Long ago and far away, I did a very small AI project in Pascal. I would not wish that on anybody. It worked, but it was just not suited to the task.

I have a public project written almost entirely in bash. It works and I'm proud of it, etc., but I have to acknowledge that a fair amount of the code and effort consists of fighting bash's code expansions which are very aggressive.

In most other languages you can have a character string and expect it to be treated just as a bunch of characters, but in bash, in most contexts, a character string will be parsed and expanded whether you like it or not. If it has any bash metacharacters in it, then you have to jump through hoops just to get bash to leave it alone.

That's one of my major motivations for learning a little bit of Python (and, if I get enough time, some Icon.)

Of course, once you get past the basics of bash, it will be really helpful to learn sed and awk. You can replace awk with Python or Perl, but I think awk is easier to use (but that's just my opinion).

And, almost every respectable language these days (even bash to some extent) supports some dialect of regular expressions which is really its own language. These get really hard, really fast, but if you master just the basics, you will multiply your power as a programmer very substantially. It's worth the effort.

This is a perfect place to illustrate point 2.

It is possible to write a regular expression that will do almost anything with some textual input. It is also possible to go mad trying!

When a regular expression starts to get convoluted, I find it way easier and faster to switch to awk and do things one step at a time and look at partial results and do normal debugging.

Debugging a regular expression usually involves just staring at it for long periods of time while muttering under your breath because, aside from the fact that it doesn't work yet, it looks perfect or, in some cases, you just can't figure out how to tell it what you want it to do.

1 members found this post helpful.

I agree with most of what has gone before, if the shell & base unix utilities are not doing what you want, try a language like perl.

It has been used on the internet for scripting for decades, lots of info about it, & many books, but there are only really 'the three' O'Reilly books needed - Learning Perl - Perl Programming - The Perl Cookbook.

1 members found this post helpful.

Everyone has their "favorite" language. But, since I like to study them (and, since I can never predict what language(s) the next project might have used already), "there's always room for one more!"

Keep up with the shell. It is useful skill. Also lean how to use awk, sed, ed, sort, join, cut, uniq, [f]grep. They will take you a long way. But as you write more complex things you may find that need more complex logic or arithmetic or even graphics. Then you need to move to a scripting language. I would suggest Python as the best mainstream one these days. I don't recommend Perl these days (though I know it well). Perl and Python fill much the same role and both have good 'ecosystems'. But Python is easier to learn and a cleaner language and is getting wide support in all sorts of areas.

1 members found this post helpful.

Hate to be pedantic, but the "shell" is not a language.

Just sayin'.

Shell scripting is used as a programming tool, and it involves source-code, so it could well be argued that it is "a language."

But it is a very limited one, wholly dependent on other little tools like "sed" and "fgrep" and so-on to do anything. It was only devised as a simple way to string a few commands together.

The point that I made earlier is that you can, for example, insert #!/usr/bin/perl (or wherever your Perl interpreter is ... or use the env command), as the first line in your file, then proceed to write the entire "shell script" in Perl. Pick your favorite "real" language. "Real" support for file-manipulation, regular expressions, string handling, arithmetic and so-on are built-in to all of them. The user of your command will neither know nor care.

Nevertheless, yes ... you will encounter some pretty unbelievable shell-scripts out there. So, you have to know something about those, too.

1 members found this post helpful.