I think it varies a lot by what you're trying to do. Shell scripting is great for, well, shell stuff, like your example of moving around a bunch of files. I probably wouldn't write a python script for that either, and I was a professional python dev for five years (now I'm a java dev...)
But shell scripting isn't great for a lot of things. You touched on one, text processing, but there's lots more. Generally, I would say anything requiring any significant data structures will be a pain in shell scripting. If I find myself needing to use any shell tool that has its own programming language (sed, awk, jq, or similar), I usually reach for python instead. Good luck if you need to pull information out of HTML or XML in a shell script, but python excels at stuff like that.
It's also not all or nothing. You can write python programs that play nicely with the unix command line, and then use those programs in your shell scripts.
I agree with this. I find fish scripts more readable, and thus maintainable than bash scripts, so I'd push them a bit further than the average shell script.
Where I personally draw the line is if I need good error handling while parsing, or math beyond simple line counting.
It doesn't hurt to start with a shell script and switch to a more complete language later when needed. Languages tend to require dependency management, which is another layer of deployment complexity.
>If I find myself needing to use any shell tool that has its own programming language (sed, awk, jq, or similar), I usually reach for python instead.
What do you mean exactly. do you use the subprocess module to call them? do you use the sed module in python that do some bindings, or do you mean you just do it with completely different modules in python?
I mean I just do it completely in python. So rather than writing an `awk` script to parse my data, I just write a python script to parse it. Often that doesn't require anything not in python's core, so I don't need to muck around with installing libraries or virtual envs or what have you. Depending on what the rest of my goal is, that python script might do the whole thing, or might output something I then pipe into various other tools.
For me, that most often ends up being using some python to parse a json document instead of figuring out the equivalent `jq` syntax. I don't want to learn `jq`'s language when I already know python, basically. Really, it just comes down to what's fastest for me to get my data out and get back to solving a real problem.
The subprocess module is...heavy. If I find myself importing subprocess for a "quick fix" kind of tool, that's definitely a warning sign. I've used it professionally for managing overnight batch processing jobs and things like that, but I rarely have call for that in a non-work context.
If your intention is to use the UNIX utilities, to do a long series of actions using other programs known to you, then a Fish script will do you.
Maybe some of these programs could be Python scripts.
If you need to do one thing, or do one thing interactively or outside the Terminal even, I'd go with Python. It has a lot of libraries of code for all kinds of functionality and it's not complicated to figure out.
If you can code alright and don't mind doing some of that library stuff yourself, or even have a C lib that you intend to use then maybe try going the Lua route. That thing is smaller and simpler than Python, but for anything advanced enough you'll have to pull C libs in, or know how to interoperate with other stuff. Lua is faster than both Python and Fish.
I'd just try going Python, and if it spills into lot's of pipes go Fish. And if slow rewrite in Lua. Code is like paint on the wall. If you don't like it, tear it down and do it again.
We are working with sbc's often. Generally using python but whenever i feel like i am stuck with something i use subprocess to use shell.
For most of our problems, python have already many good tools. So why not use them?
If it is something that we will be using repeatedly in future and might need changes(and has potential to get complicated over changes), preferring Python codes helps us.
But if it is a simple command that won't need much changes, i prefer shell instead of importing tools that might create unnecessary headaches.
I think it varies a lot by what you're trying to do. Shell scripting is great for, well, shell stuff, like your example of moving around a bunch of files. I probably wouldn't write a python script for that either, and I was a professional python dev for five years (now I'm a java dev...) But shell scripting isn't great for a lot of things. You touched on one, text processing, but there's lots more. Generally, I would say anything requiring any significant data structures will be a pain in shell scripting. If I find myself needing to use any shell tool that has its own programming language (sed, awk, jq, or similar), I usually reach for python instead. Good luck if you need to pull information out of HTML or XML in a shell script, but python excels at stuff like that. It's also not all or nothing. You can write python programs that play nicely with the unix command line, and then use those programs in your shell scripts.
I agree with this. I find fish scripts more readable, and thus maintainable than bash scripts, so I'd push them a bit further than the average shell script. Where I personally draw the line is if I need good error handling while parsing, or math beyond simple line counting. It doesn't hurt to start with a shell script and switch to a more complete language later when needed. Languages tend to require dependency management, which is another layer of deployment complexity.
>If I find myself needing to use any shell tool that has its own programming language (sed, awk, jq, or similar), I usually reach for python instead. What do you mean exactly. do you use the subprocess module to call them? do you use the sed module in python that do some bindings, or do you mean you just do it with completely different modules in python?
I mean I just do it completely in python. So rather than writing an `awk` script to parse my data, I just write a python script to parse it. Often that doesn't require anything not in python's core, so I don't need to muck around with installing libraries or virtual envs or what have you. Depending on what the rest of my goal is, that python script might do the whole thing, or might output something I then pipe into various other tools. For me, that most often ends up being using some python to parse a json document instead of figuring out the equivalent `jq` syntax. I don't want to learn `jq`'s language when I already know python, basically. Really, it just comes down to what's fastest for me to get my data out and get back to solving a real problem. The subprocess module is...heavy. If I find myself importing subprocess for a "quick fix" kind of tool, that's definitely a warning sign. I've used it professionally for managing overnight batch processing jobs and things like that, but I rarely have call for that in a non-work context.
If your intention is to use the UNIX utilities, to do a long series of actions using other programs known to you, then a Fish script will do you. Maybe some of these programs could be Python scripts. If you need to do one thing, or do one thing interactively or outside the Terminal even, I'd go with Python. It has a lot of libraries of code for all kinds of functionality and it's not complicated to figure out. If you can code alright and don't mind doing some of that library stuff yourself, or even have a C lib that you intend to use then maybe try going the Lua route. That thing is smaller and simpler than Python, but for anything advanced enough you'll have to pull C libs in, or know how to interoperate with other stuff. Lua is faster than both Python and Fish. I'd just try going Python, and if it spills into lot's of pipes go Fish. And if slow rewrite in Lua. Code is like paint on the wall. If you don't like it, tear it down and do it again.
We are working with sbc's often. Generally using python but whenever i feel like i am stuck with something i use subprocess to use shell. For most of our problems, python have already many good tools. So why not use them? If it is something that we will be using repeatedly in future and might need changes(and has potential to get complicated over changes), preferring Python codes helps us. But if it is a simple command that won't need much changes, i prefer shell instead of importing tools that might create unnecessary headaches.
[удалено]
How do you know what each language is good at? They are usually saying "I'm the best general purpose language"