Unix Shell Scripting For DBA’s (PART – 04)

Unix Shell Scripting For DBA’s (PART – 04)

reference of this article from : www.orskl.com

BASH ENVIRONMENT

In BASH ENVIRONMENT we have sub topics . They are :

1. Initialization

2. Variables and characters

3. Expansions and Aliases

4.Regular expressions

5.Grep examples

6.Pattern matching

1. Initialization 

As soon as login into server through the  putty sessions what exactly happens in the background ?

Here through putty i tried to login to remote server by specifying Host name ,port and connection type.

Once we issued all details are correct then it shows login prompt.

login as oracle user with proper authentication.

While login in initialization files will be checked.

As soon as shell logged in the default shell will run with intialization files called .bash_profile & .bashrc etc..,

In the User home location we have those hidden files.

we look on what content inside .bash_profile

Here .bash_profile contains again execution of .bashrc files.

will look on .bashrc file

In this file we have one more location called /etc/bashrc file to execute.

will look on /etc/bashrc file

Finally in this file we have one more location /etc/profile.d

System-wide configuration files

/etc/profile

When invoked interactively with the –login option or when invoked as sh, Bash reads the /etc/profile instructions. These usually set the shell variables PATH, USER, MAIL, HOSTNAME and HISTSIZE.

On some systems, the umask value is configured in /etc/profile; on other systems this file holds pointers to other configuration files such as:

/etc/inputrc, the system-wide Readline initialization file where you can configure the command line bell-style.

the /etc/profile.d directory, which contains files configuring system-wide behavior of specific programs.

/etc/bashrc

On systems offering multiple types of shells, it might be better to put Bash-specific configurations in this file, since /etc/profile is also read by other shells, such as the Bourne shell. Errors generated by shells that don’t understand the Bash syntax are prevented by splitting the configuration files for the different types of shells. In such cases, the user’s ~/.bashrc might point to /etc/bashrc in order to include it in the shell initialization process upon login.

You might also find that /etc/profile on your system only holds shell environment and program startup settings, while /etc/bashrc contains system-wide definitions for shell functions and aliases. The /etc/bashrc file might be referred to in /etc/profile or in individual user shell initialization files.

Individual user configuration files

Note     I don’t have these files?!

These files might not be in your home directory by default; create them if needed.

~/.bash_profile

This is the preferred configuration file for configuring user environments individually. In this file, users can add extra configuration options or change default settings: franky~> cat .bash_profile

~/.bash_login

This file contains specific settings that are normally only executed when you log in to the system.

~/.bashrc

Today, it is more common to use a non-login shell, for instance when logged in graphically using X terminal windows. Upon opening such a window, the user does not have to provide a user name or password; no authentication is done. Bash searches for ~/.bashrc when this happens, so it is referred to in the files read upon login as well, which means you don’t have to enter the same settings in multiple files.

In this user’s .bashrc a couple of aliases are defined and variables for specific programs are set after the system-wide /etc/bashrc is read.

~/.bash_logout

This file contains specific instructions for the logout procedure. In the example, the terminal window is cleared upon logout. This is useful for remote connections, which will leave a clean window after closing them. franky ~> cat .bash_logout

Changing shell configuration files

When making changes to any of the above files, users have to either reconnect to the system or source the altered file for the changes to take effect. By interpreting the script this way, changes are applied to the current shell session

Most shell scripts execute in a private environment: variables are not inherited by child processes unless they are exported by the parent shell. Sourcing a file containing shell commands is a way of applying changes to your own environment and setting variables in the current shell.

This example also demonstrates the use of different prompt settings by different users. In this case, red means danger. When you have a green prompt, don’t worry too much.

Note that source resourcefile is the same as . resourcefile.

 

Being as DBA we are running every time .oraenv to set our ORACLE_SID & ORACLE_HOME & PATH.

Instead of using .oraenv we can use .bash_profile by setting user defined variables

Example :

2.Variables and characters

Types of variables

As seen in the examples above, shell variables are in uppercase characters by convention. Bash keeps a list of two types of variables:

Global variables

Global variables or environment variables are available in all shells. The env or printenv commands can be used to display environment variables. These programs come with the sh-utils package.

Local variables

Local variables are only available in the current shell. Using the set built-in command without any options will display a list of all variables (including environment variables) and functions. The output will be sorted according to the current locale and displayed in a reusable format.

Variables by content

Apart from dividing variables in local and global variables, we can also divide them in categories according to the sort of content the variable contains. In this respect, variables come in 4 types:

  • String variables
  • Integer variables
  • Constant variables
  • Array variables

 

Creating variables

Variables are case sensitive and capitalized by default. Giving local variables a lowercase name is a convention which is sometimes applied. However, you are free to use the names you want or to mix cases. Variables can also contain digits, but a name starting with a digit is not allowed: prompt> export 1 number=1

VARNAME=”value”
Putting spaces around the equal sign will cause errors. It is a good habit to quote content strings when assigning values to variables: this will reduce the chance that you make errors.

Exporting variables

A variable created like the ones in the example above is only available to the current shell. It is a local variable: child processes of the current shell will not be aware of this variable. In order to pass variables to a subshell, we need to export them using the export built-in command. Variables that are exported are referred to as environment variables. Setting and exporting is usually done in one step:

export VARNAME=”value

Reserved variables
Bourne shell reserved variables
Bash uses certain shell variables in the same way as the Bourne shell. In some cases, Bash assigns a default value to the variable. The table below gives an overview of these plain shell variables:
Bash reserved variables
Special parameters
The shell treats several parameters specially. These parameters may only be referenced; assignment to them is not allowed.
Note  :   $* vs. $@
The implementation of “$*” has always been a problem and realistically should have been replaced with the behavior of “$@”. In almost every case where coders use “$*”, they mean “$@”. “$*” Can cause bugs and even security holes in your software.
Quoting characters
Why?
A lot of keys have special meanings in some context or other. Quoting is used to remove the special meaning of characters or words: quotes can disable special treatment for special characters, they can prevent reserved words from being recognized as such and they can disable parameter expansion.
Escape characters
Escape characters are used to remove the special meaning from a single character. A non-quoted backslash, \, is used as an escape character in Bash. It preserves the literal value of the next character that follows, with the exception of newline. If a newline character appears immediately after the backslash, it marks the continuation of a line when it is longer that the width of the terminal; the backslash is removed from the input stream and effectively ignored.
Single quotes
Single quotes (”) are used to preserve the literal value of each character enclosed within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash.
Double quotes
Using double quotes the literal value of all characters enclosed is preserved, except for the dollar sign, the backticks (backward single quotes, ) and the backslash.
The dollar sign and the back ticks retain their special meaning within the double quotes.
The backslash retains its meaning only when followed by dollar, back tick, double quote, backslash or newline. Within double quotes, the backslashes are removed from the input stream when followed by one of these characters. Backslashes preceding characters that don’t have a special meaning are left unmodified for processing by the shell interpreter.
A double quote may be quoted within double quotes by preceding it with a backslash.
ANSI-C quoting
Words in the form “$’STRING'” are treated in a special way. The word expands to a string, with backslash-escaped characters replaced as specified by the ANSI-C standard. Backslash escape sequences can be found in the Bash documentation.
Locales 
A double-quoted string preceded by a dollar sign will cause the string to be translated according to the current locale. If the current locale is “C” or “POSIX”, the dollar sign is ignored. If the string is translated and replaced, the replacement is double-quoted.
Check default variables:

Execute successful command and failure command and check the result using $?
If value comes zero(0) the previous command executed successfully.
In case if it comes with any value the previous command is failure.
[

Write a script to understand functionality of $1 $2 $3 and $#.

Check the file permissions and  give the executable permissions to a file.

Now execute the script3.sh file along with the arguments.

Understand purpose of \, ‘ and “.

Load variables into a file and run source command.

 

Thank you …
Note: Please test scripts in Non Prod before trying in Production.
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5.00 out of 5)
Loading...

Add Comment