Bash shell scripting

[rarsa]

This command does not execute a function built into the shell itself, unlike commands such as rm and grep. Do I have this much correct?.

The concept is correct: there are built in commands that are part of bash. There are other commands that are sand alone programs.

FYI...rm and grep are external commands, not a shell commands.

Here is the list of built in commands

http://linux.about.com/library/cmd/blcmdl1_builtin.htm

Whenever you are in doubt you can execute "which" with a valid command

Code: Select all

which <command>
e.g.
which grep

If it returns you the file path, then it is an external program. If it complains, then it is a shell command.

Note that I said "valid command", if you use "which" with an invalid command or a program that is not in your path, then it will complain too.

[Gn2]

Bash is a very powerful command shell - a "shell" because it may stand alone - without need for most GUI functions.

As in nature a "shell" may contain most anything inside it.
Bash has many desirable features,>
Auto command line completion_
"Wildcard" letter substitution
"Built-in" Internal & external functions
A "prompt" that is user configurable & may enfold many functions
"Reserved" character functions - (Bash internal use only)
Built as an execute only - or await user input {interactively}
The login shell (in the INITIAL = initrd boot image) usually ASH is an example of "interactive" use
Once control is passed to the kernel. file system mounted, which CLI used has been determined by the distribution

Part of the confusion arises in ability to make a script executable.

An executable may include - functions as desired to call other internal/external commands,
take those results and perform other actions.
The script may also embed other languages/functions that are invoked If/when the dependencies
for them are available as dynamic libraries -already installed on System.

What you now have is a executable - coded partially in binary and partially in text.

If some binary contains their dependencies in the code - it is a STATIC binary
= Self contained, the dependencies are included

Apps built requiring dynamic libraries - are compiled with specific dependencies.
If those dependencies are not met (not available), versions don't match -
or the command executable path environment is incorrect-

The output is intercepted by the error handling procedures of the kernel -
In most cases, an error Msg is output to screen (I.E. segment fault) and process halted to limit further system damage.
In extreme error cases, a kernel "dump" is output (contents of memory locations of events)
In others - the system may "lock" (kernel panic) > a kernel freeze - unable to continue ~ a power reset is Req'd.

Please read Bash manuals and for Linux basics, see such as the YoLinux (URL)
It will be a big aid to purchase such as the O'Reilly manual "Linux in a Nutshell"
It is much the same as the built-in system help (man or info pages), but w/explanations.
Their prime use however is as an "cheat-sheet" to recall parameter syntax.

They are not suitable to LEARN Bash... any more than a dictionary may teach a new language.
One of best Bash manuals is downloadable, BASH - on-line

Any data in this forum thread was available on line.

[une]

Thanks again. I think I need to do some generic Linux research.
I am using a book called;
"Linux & Unix Programming Tools" by Sarwar
to get started on my Linux programming quest. It is actually part of a computer science course I am taking via the Internet.

I am starting to work my way into the book and am finding other commands that my Puppy Linux system does not recognize. The latest command I tried to use that Puppy Linux did not recognize was whereis.

My Linux system at home (Mandrake 10) recognizes commands such as chsh and whereis. It seems there is a whole other set of commands that one commonly uses from the Linux command line that are not a built in within BASH or located elsewhere in Puppy Linux.

My apologies Gn2 but I did not understand all of what you detailed in your last post, as I said I will do more research elsewehere.
However, is there a package I can download and install (then include in a remastered CD for constant use) that will make available from the command line the entire range of Linux commands that are commonly used?
I looked at the the built in commands listing suggested in this thread and found some examples that have confused me a little. Stick with me here if you have time, following are my experiments;

In this thread it has been mentioned that grep is not a built in BASH command, thus as expected to me when I execute the following I get a response as follows from the system;
$which grep
/bin/grep
This indicates to me that the command grep is not built in within BASH and the application that is grep is located in /bin.

break is a built in command within BASH apparently, so when I execute
$which break
$
I get no response at all, just another prompt as shown above. Does this lack of system response indicate that break is a BASH built in command?

printf is also an built in command within BASH it seems, however when I execute the following I get a response as follows;
$which printf
/usr/bin/printf
This confuses me as this indicates to me that to execute the printf command the system uses an external application stored in /usr/bin.

whereis is not available at all, however when I execute the following I get a response as follows;
$which whereis
$
This confuses me as this lack of system response is the same as for break, which I deduced meant it was a BASH built in command.

There are some other "non BASH built in" commands available in my Puppy Linux system such as date
$which date
/bin/date

and time

$which time
/usr/bin/time

which are included in my Puppy Linux.

Thus I am confused as to why what I think are supposed to be BASH built in commands, seem to execute from external (to BASH) locations (eg printf)
I am also confused why some external commands such as grep are included in Puppy Linux and why others are not (eg whereis)

Perhaps there may be other commands I will be asked to use when working through my textbook that are not either built in within BASH nor available from elsewhere in the Puppy Linux OS.

I want to be able to work through this textbook using Puppy Linux.

[GuestToo]

My Linux system at home (Mandrake 10) recognizes commands such as chsh and whereis

the free version of Mandriva is 4,438MB (commercial version is larger) ... Puppy is less than 80MB

is there a package I can download

i'm not sure, but i think there is a dotpup package of the GNU utilities somewhere

This indicates to me that the command grep is not built in within BASH and the application that is grep is located in /bin

which grep shows that there is an executable file named grep in one of the directories in the PATH (type echo $PATH) ... whether grep is a bash builtin function, or not ... if there is no executable file named grep in a dir in PATH, it will not display a result ... whether grep is a bash builtin function, or not

which does not tell you about bash builtin functions

Does this lack of system response indicate that break is a BASH built in command?

no, it tells you that there is no executable file named break in the PATH dirs

This confuses me as this indicates to me that to execute the printf command the system uses an external application stored in /usr/bin

which tells you that there is an executable file named printf in /usr/bin ... this does not tell you whether there is a bash builtin function named printf

if you type ash, you will run Busybox's ash shell ... if you then type help, it will show you a list of builtin functions in the ash shell ... printf is not an ash builtin function, so ash will run an external executable file if you run the printf command

if you type help in a bash shell, you will see that printf is a bash builtin function ... if you run the printf command in a bash/sh shell, you will be running the internal bash function, not the external executable file

This confuses me as this lack of system response is the same as for break, which I deduced meant it was a BASH built in command

this means there is no executable file named whereis in PATH

there is a similar and useful bash script called where ... dotpup package here: http://www.murga-linux.com/puppy/viewtopic.php?&t=10469

I am also confused why some external commands such as grep are included in Puppy Linux and why others are not (eg whereis)

grep is extremely useful (essential) ... whereis is not essential at all (obviously, since Puppy runs without it)

if you delete /bin/grep, you will find that Puppy will be severely broken ... many programs will no longer work ... Puppy may no longer be able to finish booting

I want to be able to work through this textbook using Puppy Linux

Puppy is 80 megs, not 4 gigs ... Puppy is different, it is designed to be small and fast and to run completely in ram ... it is not possible to small and fast and to run completely in ram and to have installed by default every program and utility and library that a distro like Mandriva has installed

[une]

Thanks a lot for your clear answer. I will contemplate further.

[une]

I am now guessing there are a plethora of Bash scripts which perform many different functions, and these are different to built in Bash commands. An example being grep. I take it one day in the distant past someone thought "I am going to create a script called grep that will be good for pattern matching". They created it and people liked it. Thus it became a commonly included Bash script (utility?), while never actually being a built in Bash command. Do I have this correct?

I am also guessing that as I discover commands that are not recognized by Puppy, if I want to use them within Bash on my puppy OS I would have to download and install what you refer to as a "dotpup" package. Is this correct?

[rarsa]

Ok, here we go une:

Not everything you can execute from bash are bash commands (I think you already understood this)

Not every non-bash thing you can execute is a script.

Scripts are programs written in interpreted languages.

bash IS NOT a script, bash is a binary application.

Although I don't know why you care on knowing the difference, the difference only matters if you are planning to write a script or a binary program. For the most part for the day to day user it does not really matter.

[une]

Thanks for sticking with me. Every answer I receive to what I am sure are sometimes nonsensical questions reveals a lot to me. The waters are clearing, slowly.
I am doing a computer science course and decided to take a unit named "The Linux/Unix programming environment". Hence I am getting myself as prepared as I can before the unit starts in 2 weeks. My experience to date is in basic C++ and Java programming via emacs (as well as some less "technical" subjects like systems analysis and design and knowledge management).

When you write a script is it analogous to (perhaps for want of a better word) a "macro"?
Perhaps alternatively a script is compiled in some way to create a binary executable application?
Perhaps the script is interpreted by another application (interpreter?) at run time when it is executed?

Is the binary application named BASH the result of compiled C or C++ code?
Is for example grep a script or a binary executable application?

Thanks again for such detailed help so far.

[GuestToo]

yes, bash is an executable binary program written in C ... the C source is compiled by a compiler (gcc) to produce an executable binary file

some languages are interpreted, not compiled ... these languages execute each command of the "source" (the script) line by line

a script could be compiled to generate a binary executable, as opposed to being executed ... there is a C interpreter, for example

yes, when a script is "run", an interpreter (a binary executable, often written in C) executes and processes the script, line by line

grep is a binary file ... you could right click the file and "open as text" ... a script will be text that you can read ... or you can right click the file and click "properties" to see what kind of file it is

[Lobster]

Puppy makes extensive use of scripts

http://puppylinux.org/wikka/bash

http://puppylinux.org/wikka/ShellScripts

If Barry reads this be interested what proportion of his programming time is spent on script - I should imagine 90%?

[une]

Thanks all for the detailed responses. My journey continues!

[une]

OK, I think I am progressing. How does the following sound?
When I see the prompt in a terminal
sh-3.00#
I am using Bash. The "sh" in the terminal prompt looks suspiciously like it has something to do with the shell named sh. However when you use sh in Puppy you are actually using Bash due to the symbolic link from sh to Bash.

Some commands I can execute from the terminal are "Built In" Bash commands. External (to Bash) commands that most Linux systems have are provided by Busybox in Puppy. Busybox provides executable files for these commands that are slimmed down versions to save space.

Where are the man pages for external commands? Perhaps they are not included to save space. Executing the man command (from the prompt sh-3.00#) creates all sorts of problems. A Dillo window appears (with errors) and the terminal shows many error messages. Something weird happened though, for an experiment I entered the command

sh-3.00# bash
#
My command prompt changed. Am I now operating in a shell within a shell? Curiously, when I then tried a man command, I got a Dillo window that worked and showed a link to online manual pages. Why the prvious attempt to access man pages did not have the same result eludes me.

Any comments on my wanderings welcomed.

[GuestToo]

no, Puppy does not have the full "man" program and all the help files, to save space ... you can read the missing files on the internet, for example, http://phpunixman.sourceforge.net/

yes, sh is really bash, but when bash runs as if it is named sh, it behaves slightly differently ... for one thing, when bash starts, it executes /root/.bashrc ... when bash runs as sh, it does not execute /root/.bashrc ... this can cause some confusing differences when running a shell script, either because of the first line ofthe script:

#!/bin/sh

or

#!/bin/bash

or because the default shell is set to /bin/sh or /bin/bash (you can set the default shell that runs by putting a line like this in /etc/profile.local:

export SHELL=/bin/sh

you can have sh execute an intitialization file when sh starts by putting the name of the file in the ENV variable, by putting a line like this in /etc/profile.local:

export ENV=/root/.bashrc

when you type sh or bash or ash, you start a new program running, which is a shell ... when you end the program by typing exit or by pressing ctrl+D, the new shell program stops and you are back in the original shell program

you can set the shell prompt if you like

you could get rid of the messages when "man" runs by editing /usr/bin/man, like this:

leafpad `which man`

if you edit the "man" script like this, you will not see the messages:

near the top of the file, change this:

BBAPPLETS="|addgroup|adduser|adjtimex

to this:

(
BBAPPLETS="|addgroup|adduser|adjtimex

at the bottom of the file, change this:

fi

to this:

fi
) > /dev/null 2>&1

that is, you run the entire script in a new process, in brackets: ( script )

and you send all messages in the script to /dev/null:
( script ) > /dev/nul 2>&1

the sh shell and the bash shell behave slightly differently, and have different environmental variables set up, so a program that might run properly in a sh shell might not run properly in a bash shell, or vice versa ... for example, dillo

type env or type set to see the env variables

[GuestToo]

normally, you need to specify the full absolute path to the program that will run a script, like this:

#!/usr/bin/wish
# a tcl/tk script ...

but you can have the script search for the program to run in the PATH directories, and you can have command line paramters, like this:

#!/usr/bin/env wish -name my-script -geometry 640x480
# a tcl/tk script ...

this will run the script with the program "wish", which should be found where ever the wish program is, as long as the dir is in PATH, and it will run with the parameters -name my-script and -geometry 640x480

just a trick i thought i would mention

[une]

Thanks, I will experiment further. The further I dig the more complexities I discover. I haven't even started any actual shell scripting yet and I have learned a heap of new stuff! The environment itself holds many unkowns and dangers for new players.