LinuxQuestions.org - New angle: What can't I do with Bash?

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - New angle: What can't I do with Bash? (https://www.linuxquestions.org/questions/programming-9/new-angle-what-cant-i-do-with-bash-867065/)

@theKbStockpiler

I think you're trying to be way too philosophical about this.

BASH is just a program to conveniently launch other programs. That's it.

Quote:

Originally Posted by MTK358 (Post 4313264)

@theKbStockpiler

I think you're trying to be way too philosophical about this.

BASH is just a program to conveniently launch other programs. That's it.

Well put.

I'd like to add that theKbStockpiler also uses terminology that is not generally accurate, and probably perpetuates many of his misunderstandings. For example, the phrase 'when you open a BASH Application directly', which I think must mean 'run a text-mode application from a shell commandline'. Conceptually, 'open' and 'run' are distinct, where running implies execution of code, and opening is simply creating an access point to a file. Other than shell scripts, there is really no such thing as a 'BASH Application'. Bash holds no special relationship with any application that I know.

Another broad misunderstanding that I believe the OP holds is that Bash somehow contributes something to the runtime 'environment' (where the term is used in a general sense, not referring to the actual memory space holding variables and other data). Such is not the case. A text-mode application's only attachment to the shell that launched it is that the shell is its parent process and provider of its arguments. The shell that launches an application may set up certain environment variables, establish some particular host configuration such as terminal configuration or behavior, and passes arguments to the launched process, but does not provide any kind of services to the child process. There is no API that provides access to the parent shell. Actually, this is true of any application, text-mode or GUI, launched by Bash or other common shells.

A shell is the common term for applications that provide a commandline user interface. Bash is the shell most commonly used in Linux. It is the more recent version of the Bourne Shell, and the name is actually a sort of acronym for "Bourne Again SHell". Other common shells are Korn shell, and C-Shell. The little programs that most shells are capable of interpreting are what we call scripts. I'm not sure I understand your last question, but I think you asked whether I really meant writing shell scripts, and not an actual shell. This is not what I meant at all. I meant that a constructive exercise is to write an actual simple shell. You could call is theKBSShell.

--- rod.

Why BASH? Because what you need to do is 'trivial' and repetitive...

Okay...

@theKbStockpiler & Sergei: The concept of shell-scripting, especially as it pertains to Systems Administration, is the idea that you are likely going to have to do several repetitive tasks over and over again that you *could* do from the CLI, but would rather put your skills to use by automating as much as you can into a shell script. This should make you more efficient and your job much easier.

Now, as has been pointed out, BASH can call any executable on a system, so it has the capability of being *very* powerful, and if improperly used, can cause data loss, data corruption or system instability. So, when I say 'trivial' above, I refer to the System Administrator's perspective of the task at hand being accomplished within 15-20 minutes from the CLI, and not that the end-users won't even notice if the task was accomplished or not.

As an example, a common task for System/Network Administrators is the updating of DNS records. The good admins that I have met keep a zone-file entry in a secured CVS/SVN/etc. server to keep track of changes in DNS, as well as make sure they have something to go back to should something go seriously wrong in the update. (Does anyone remember when Micro$oft pushed out a DNS update that killed access to Hotmail for a couple days? :p Well, there you go!) A BASH script is a perfect tool for such a task: You make the changes to the copy of the zone-file in your local filesystem, then fire off the script to check-in the updates to CVS and push it to the DNS server. The script would save you about 10-15 minutes for each update.

Another quick example is a situation where you have a filesystem with a couple terabytes of images, and every image should have a thumbnail. Then, an end-user sends you an email stating that some images they need don't seem to have thumbnails. You check logs and find that there had been a few days of images being added, but no thumbnails were generated. So, you now have a couple options:

You can go through the filesystem by hand and then generate the missing thumbnails from the CLI. (Not good, time-wasting)
You can go through the logs and find every folder that has missed getting thumbnails, and then generate them from the CLI. (Smarter, but still time-wasting.)
You can write a script to comb the logs and generate the thumbnails for each folder that missed them. (Smarter still. Doesn't waste your time, but you can't be sure the filesystem is complete.)
You can write a script to check through the *entire* filesystem and make sure every image has it's thumbnail by generating the ones that are missing. (Very smart and complete.)

So, when it comes to the SysAd's toolbox, I tend to think of BASH as being the Phillips-head screwdriver. Hugely useful, but, as also stated above, not the right tool for every situation. It certainly can save you *hours* of work if used correctly.

Now, if you want to build your knowledge and skills with BASH, I recommend going through The Advanced BASH-Scripting Guide at The Linux Documentation Project. An excellent guide with examples and plenty of exercises to try. I still use it as a reference now and again. Check it out.

HTH.

Quote:

Originally Posted by ShadowCat8 (Post 4329541)

Okay...

... Sergei: ...

I mostly write in Perl - have yet to find a true need to mostly write in 'sh'. Though recently I wrote a primitive script in 'sh' - to be called from GNU Octave.

On a resource limited embedded system I might be forced to write in 'sh'.

Quote:

Originally Posted by Sergei Steshenko (Post 4330373)

I agree with that. I think that if Perl had a sort of interactive console like Python does, maybe with a few small enhancements, I could see using it as a replacement for a conventional shell, in certain circumstances. While I do also write a fair amount of stuff in bash/sh, I also find myself writing perl one-liners almost equally as much. However, the one advantage I find with writing 'one-liners' in bash is that I can write more naturally because bash will recognize when a newline is just a separator between statements, and not try to execute the commandline until it is syntactically complete. I'd really like it if there was a way to compose Perl one-liners on the commandline in a similar way.
--- rod.

Quote:

Originally Posted by theNbomr (Post 4330617)

... if Perl had a sort of interactive console like Python does ...

Try to perform web search on

perl shell

- you'll find more than one. Also, PDL (Perl Data Language) has an interactive shell as default.

And, of course, one can simply write:

Code:

for(;;)

  {

  my $line_to_be executed = <STDIN>;

  eval $line_to_be executed;

  print STDERR "\$\@=$@" if $@;

  }

and try his/her code in that loop.

Or is it just a catchy image?

Thanks for all the great replies. Although I don't believe that what I think bash is and what other members believe it is , is the same, the context I received helped form an opinion of it in which I believe I should be able to utilize.

I think Jeremy; as in LQ's Jeremy, has it" summed"up with the LQ logo. The Penguin is the same penguin that is gradually being overcome with the answer in steps with the help of other members. The Penguin has to come to the understanding it's self and that is the way knowledge works "internal understanding".

Quote:

Originally Posted by theKbStockpiler (Post 4331105)

...
I think Jeremy; as in LQ's Jeremy, has it" summed"up with the LQ logo. The Penguin is the same penguin that is gradually being overcome with the answer in steps with the help of other members. The Penguin has to come to the understanding it's self and that is the way knowledge works "internal understanding".

??????????????

What does this discussion have to do with Linux specifically ? How is it different for Solaris, *BSD, AIX, HPUX, etc. ?

korn shell is nicer than bash for scripting

:-)

My rules of thumb:
messing about with files: shell
messing about with strings: perl
messing about with bytes: C/C++

@theKbStockpiler: I understand what you mean about bash ;)

Quote:

Originally Posted by Sergei Steshenko (Post 4330744)

Try to perform web search on

perl shell

- you'll find more than one. Also, PDL (Perl Data Language) has an interactive shell as default.

Interesting. So far it looks like Psh is the common favorite. Yours?

Correction, I think...

Code:

my $line_to_be executed = <STDIN>; # should be $line_to_be_executed ???

Whilst trying Sergei's little code snippet, I discovered that if I am typing a bit of perl code at a bash commandline, when I enclose the code in single quotes, that readline seems to know that embedded newlines (ie.pressing the 'Enter' key) are interpreted just like they are when interactively typing a shell script. This actually addresses my main issue, and I'm tickled to know about this. Thanks for leading me to that little nugget.

In the following, the tokens '<Enter>' should be interpreted as me pressing the 'Enter' key

Code:

 perl -e 'for(;;)<Enter>

  {<Enter>

  my $line_to_be_executed = <STDIN>;<Enter>

  eval $line_to_be_executed;<Enter>

  print STDERR "\$\@=$@" if $@;<Enter>

  }'<Enter>

#

#  Here, the code is complete and begins to execute...

#    ... just the thing I was looking for.

--- rod.

Quote:

Originally Posted by theNbomr (Post 4331712)

Interesting. So far it looks like Psh is the common favorite. Yours?
...

Once I tried http://cpan.uwinnipeg.ca/htdocs/Zoidberg/Zoidberg.html .

But my approach is different - I have a 'junk.pl' file in which I try little Perl code snippets, e.g. regular expressions and test cases for them. I find it to be actually time saving - editing in my favorite text editor and not having to deal with shell quoting issues is a relief.