Thinking in bash?
- Thread starter oslon
- Start date
Technically Bash is an imperative, procedural language just like C. It has variables and you do things step by step, in a certain logical order. The main difference between bash and C is that bash is an interpreted scripting language, whereas C programs have to be compiled to a native binary format before they can be ran. The syntax of bash is also slightly different to C - but aside from the differences in syntax, you still need to solve problems in the same way. Using a set of logical steps to reach the desired outcome.
The cool thing about Bash is - you can create command lines which can run/chain -together multiple scripts/programs, passing the output of one script/program to the input of another using pipes/inter process communication.
So bash is kinda like glue in a way. You can use it to stick a bunch of other scripts/programs together, ha ha.
With C, you can create a bunch of small programs that do very limited things (you can also create bigger, more complex programs, but in Unix/Linux, smaller, more atomic programs are preferred wherever possible!). In Unix/Linux environments, we already have a ton of small programs like ls, sed, awk, cut, grep etc, which are all C programs.
Using bash, you can create scripts that run one or more of these programs in a sequence, to maniuplate data which is passed between the programs ran in the script.
So think of C as a way of creating individual software components that deal with specific input in a particular, limited way. And think of bash as a way of chaining the inputs/outputs of multiple programs (or scripts) in order to perform more complex transformations on data.
When solving problems using bash scripts, as long as you know about the format of the data you're going to be using, you then need to work out what programs (or scripts), you'll need to run together, in which order, in order to apply the required transformations to the data. You can use variables in bash to store the results from running certain commands. Or you might want to use temporary files, or just pass data directly from one set of commands to another using pipes.
So in bash, you're still solving problems in a very similar way to C. It's still procedural, it's still a linear process of logical steps. But with bash, you can rely on entire pre-existing programs and scripts to take care of larger chunks of whatever processes you're undertaking in your scripts.
In a C program, you have to take control of every tiny, little logical step along the way in your program. Whereas in bash - you're chaining together a bunch of pre-made black boxes in order to do specific things.
I've been a professional C/C++ programmer for over 20 years now. And I've probably been using bash for even longer than that. Sometimes a bash one-liner, or a script is all I need to solve a particular problem.
But when writing a bash script, I might get stuck on something - I might not be able to find a command, or sequence of commands that will solve a particular problem. In cases like that, I might have to create a dedicated C/C++ program, or a perl script, or a python script, or a ruby script to do it - which I can then plumb into my bash scripts to perform any missing operations on data.
But overall, the thought process when writing a bash script isn't much different to writing a C program, because you just have to do things in a logical sequence, in order to solve a problem. Again, like I said, in bash, you're just chaining a bunch of pre-made black-boxes together, in order to solve problems.
The cool thing about Bash is - you can create command lines which can run/chain -together multiple scripts/programs, passing the output of one script/program to the input of another using pipes/inter process communication.
So bash is kinda like glue in a way. You can use it to stick a bunch of other scripts/programs together, ha ha.
With C, you can create a bunch of small programs that do very limited things (you can also create bigger, more complex programs, but in Unix/Linux, smaller, more atomic programs are preferred wherever possible!). In Unix/Linux environments, we already have a ton of small programs like ls, sed, awk, cut, grep etc, which are all C programs.
Using bash, you can create scripts that run one or more of these programs in a sequence, to maniuplate data which is passed between the programs ran in the script.
So think of C as a way of creating individual software components that deal with specific input in a particular, limited way. And think of bash as a way of chaining the inputs/outputs of multiple programs (or scripts) in order to perform more complex transformations on data.
When solving problems using bash scripts, as long as you know about the format of the data you're going to be using, you then need to work out what programs (or scripts), you'll need to run together, in which order, in order to apply the required transformations to the data. You can use variables in bash to store the results from running certain commands. Or you might want to use temporary files, or just pass data directly from one set of commands to another using pipes.
So in bash, you're still solving problems in a very similar way to C. It's still procedural, it's still a linear process of logical steps. But with bash, you can rely on entire pre-existing programs and scripts to take care of larger chunks of whatever processes you're undertaking in your scripts.
In a C program, you have to take control of every tiny, little logical step along the way in your program. Whereas in bash - you're chaining together a bunch of pre-made black boxes in order to do specific things.
I've been a professional C/C++ programmer for over 20 years now. And I've probably been using bash for even longer than that. Sometimes a bash one-liner, or a script is all I need to solve a particular problem.
But when writing a bash script, I might get stuck on something - I might not be able to find a command, or sequence of commands that will solve a particular problem. In cases like that, I might have to create a dedicated C/C++ program, or a perl script, or a python script, or a ruby script to do it - which I can then plumb into my bash scripts to perform any missing operations on data.
But overall, the thought process when writing a bash script isn't much different to writing a C program, because you just have to do things in a logical sequence, in order to solve a problem. Again, like I said, in bash, you're just chaining a bunch of pre-made black-boxes together, in order to solve problems.
I think a lot of people don't approach "shell scripting" as "programming" but more as "a quick and dirty hack" - and there -is- a place for an ad hoc "one off" script that just gets the job done.
But I find that way too often a script that starts out that way eventually morphs into something more substantial and then you'll be glad you were a C programmer first and thought about your script as a "real" programming effort from the very start.
The phrase "Thinking in Bash" brings to mind three things, one of which may or may not be applicable in your case:
The iffy one is this: I was advised long ago, and have never been sorry for following the advice, not to program specifically in Bash but to program in "sh" so as to not get into the habit of using scripting features that may or may not be present on any given UNIX/Linux system. There are some nice features in Bash - but does this, that or the other system have Bash installed? My own systems, by default, use busybox ash, though I can load Bash easily enough when needed. I occasionally run across a script with the shabang "#!/bin/bash" instead of "#!/bin/sh" (even though it uses none of the advanced features of Bash), resulting in a message like, "sh: <script_name>: not found", when clearly <script_name> -is- present, -is- executable and -is- located in a directory mentioned in $PATH. It's enough to drive me to drinking! (*) .
I'm not saying, "never use Bash", only to use it when needed but maybe -not- to use it by default. I think (someone correct me if I'm wrong) that most systems that use Bash by default also symlink /bin/sh to point to /bin/bash and that when invoked as "sh" it will complain about "bashisms"
The second one is that to "think in bash" (or in sh) you need to "think in linux" - you need to be well versed in the unix/linux utilities - what's available, what are the available options for each, what does their output look like, the use of pipes, etc. After decades, I've only just started to get a grip on sed and awk and I realize now that I've written -a lot- of unnecessary lines of script over the years because I didn't put in the effort to learn them earlier. And don't forget regular expressions. I'd say there's actually more to it than C.
The third is to not think in C nor in Bash but to think in "Programmer". Ignoring the (possibly necessary) cancer that is "object oriented programming", you can try out a bunch of programming languages like C, pascal, etc - even BASIC and find that, while some of the features and details differ, they are enough alike that now you are thinking in that common mindset. Then treat yourself to a few weeks with each of FORTH (some of Leo Brodie's books are available on line for free) and MUMPS (gtm or O'Kane or even Intersystems Cache). Each of those willpervert mature your "programmer mindset" just a little bit and help you to think outside your previously unnoticed box.
*) it really doesn't take all that much!
But I find that way too often a script that starts out that way eventually morphs into something more substantial and then you'll be glad you were a C programmer first and thought about your script as a "real" programming effort from the very start.
The phrase "Thinking in Bash" brings to mind three things, one of which may or may not be applicable in your case:
The iffy one is this: I was advised long ago, and have never been sorry for following the advice, not to program specifically in Bash but to program in "sh" so as to not get into the habit of using scripting features that may or may not be present on any given UNIX/Linux system. There are some nice features in Bash - but does this, that or the other system have Bash installed? My own systems, by default, use busybox ash, though I can load Bash easily enough when needed. I occasionally run across a script with the shabang "#!/bin/bash" instead of "#!/bin/sh" (even though it uses none of the advanced features of Bash), resulting in a message like, "sh: <script_name>: not found", when clearly <script_name> -is- present, -is- executable and -is- located in a directory mentioned in $PATH. It's enough to drive me to drinking! (*) .
I'm not saying, "never use Bash", only to use it when needed but maybe -not- to use it by default. I think (someone correct me if I'm wrong) that most systems that use Bash by default also symlink /bin/sh to point to /bin/bash and that when invoked as "sh" it will complain about "bashisms"
The second one is that to "think in bash" (or in sh) you need to "think in linux" - you need to be well versed in the unix/linux utilities - what's available, what are the available options for each, what does their output look like, the use of pipes, etc. After decades, I've only just started to get a grip on sed and awk and I realize now that I've written -a lot- of unnecessary lines of script over the years because I didn't put in the effort to learn them earlier. And don't forget regular expressions. I'd say there's actually more to it than C.
The third is to not think in C nor in Bash but to think in "Programmer". Ignoring the (possibly necessary) cancer that is "object oriented programming", you can try out a bunch of programming languages like C, pascal, etc - even BASIC and find that, while some of the features and details differ, they are enough alike that now you are thinking in that common mindset. Then treat yourself to a few weeks with each of FORTH (some of Leo Brodie's books are available on line for free) and MUMPS (gtm or O'Kane or even Intersystems Cache). Each of those will
*) it really doesn't take all that much!
Bash is a command line Shell, don't forget that. You can't compare. In Bash, question is more : OK, what commands can I actually run ? How far does my function set go. Constantly one is running the limit of what the commands allow you to. In such a way that by having lots of experiencing in Bash, you probably know every function available. Just because the set is more limited.
In C, there's a function for EVERYTHING, you'll never know them all. You get to know the ones in the area you're working, and then there's much more ..
MikeRocor wrote:
That nails it for me. It facilitates being a "multilingual" programmer which liberates one from the limitations of any one programming language, and makes the programming world your oyster.
I don't think you can really think in a programming language, given the fact all logic exists in pseudo code really.
Then, you think how the pseudo code logic is translated in <insert any language here>
And then you actually see how it is coded (worded), and if it is working in that language.
Then, you think how the pseudo code logic is translated in <insert any language here>
And then you actually see how it is coded (worded), and if it is working in that language.
