Sourcing a shell script in bash

March 9, 2014 Leave a comment

When a script is called using “.” or “source” command, then a script is said to be sourced. There are different ways of sourcing a script which are given below:

source script-name


. script-name

The difference between executing a script normally and sourcing a script is that, when a script is normally executed, a new shell is created and commands inside the script are executed in the new shell. The environment variables of the parent process are made available to the child process, but the local variables are not.

But when a script is sourced, the commands of the sourced script are executed in the same shell as the script from which it is called. And therefore all the local variables of the parent script is available to the sourced script. It is typically executed as if the contents of the sourced script are the contents of the parent script.

Generally scripts are sourced, when the variables of a script is required to be used inside another script, so that each of the variables which are required do not have to exported to be made available inside the sourced script.

Lets verify this with simple proof of concept.

Write a script as given below, which will be used to invoke the other script in different ways.

echo “In caller script”
echo “$0″


export BLOG=”$BLOG”

echo “BLOG=$BLOG”

ps -o pid,ppid,cmd | grep -v “ps”

echo “————————————”
echo “Inside directly called script”

echo “————————————”
echo “Inside sourced script”
. ./

echo “————————————”
echo “Back in the caller script”
exit 0

Here is the caller script, we have defined two variables, BLOG and PLATFORM. variable BLOG is also exported using the “export” command, then the contents of variables are displayed and then there is ps command executed to display the processes currently running in the terminal from which it is called. Output of ps command is formatted such that it displays process id, parent process id and the name of the process. Then we have a child script “” which is normally called and then the same script is called again, but this time it is sourced.

Now lets define the contents of the called script.

echo $0
echo “BLOG=$BLOG”

ps -o pid,ppid,cmd | grep -v “ps”
exit 0

Inside called script we display the value of variables BLOG and PLATFORM, which is not defined in this script. and then we have a ps command, which is the same one as used in the caller script. By default ps command also prints the process details of itself, so to reduce the clutter of output we ignore the information about ps command itself, by piping it to grep. Then we have an exit command at the end of script.

Now as we have contents of both caller script and called script in place, let’s execute the script and look at the output. When the caller script is executed from the terminal, this is the output we get:

In caller script
4291  2884 bash
16158  4291 /bin/bash ./
Inside directly called script
4291  2884 bash
16158  4291 /bin/bash ./
16161 16158 /bin/bash ./
Inside sourced script
4291  2884 bash
16158  4291 /bin/bash ./

Now let’s analyze the output of the scripts. output:

  • First the display statements in the caller scripts are executed and it is as expected.
  • Then the ps command output has two lines, which shows the process currently executing in the terminal from which the script was called, first line is the bash shell with process id “4291”, which is executed when a terminal is opened. Next line shows the process id of the caller script “16158” and the command name of the process.

output of when directly executed:

  • Next the display statements of script output which is called normally shows variable BLOG has a value, because BLOG is exported in the script and as this is the child process of script, it is made available here, but PLATFORM variable is not, because this runs as an independent child process.
  • ps command output of the directly called script shows that the is indeed the parent process of script.

output of when sourced:

  • Next the display statements of called script which is sourced shows that, command name of script is same as that script(output of “echo $0”). Then the variables both has a value, even as the PLATFORM variable is not exported. As a new bash shell is not created this time and these variables become local to
  • finally ps command output proves that there is no new process created this time, when is sourced.
  • Also, it is important to note that the display statements “Back in the caller script” is not printed as “exit 0” is given in When that statement is executed in the script is exited as well, because both and runs under same process and this does not happen when it is called normally.

Hope this example is useful in understanding the concept of sourcing shell scripts.

Fix Touchpad tap to click not working on Linux mint 16 petra

January 18, 2014 Leave a comment

Touchpad tap to click is by default disabled on Linux mint 16 and you can easily enable it by going to System settings -> Mouse and touchpad -> Touchpad  and selecting “Enable mouseclicks with touchpad”. This is fairly straight forward.

enable touchpad tap to click

enable touchpad tap to click

However, for some people who have upgraded from older versions of Linux mint instead of doing a fresh clean install of Mint 16, they might have two versions of system settings installed, like shown below.

Screenshot from 2014-01-18 12:35:53

Both are different system settings application and not displayed twice due to some menu configuration error, it’ll become obvious once you open both side by side.The fact that both applications have the same name and icon is very deceptive for the normal eyes.You might have used both applications but you might be unaware of this fact, unless you look for it. Here, is a screenshot showing both opened side by side.

screenshot showing a comparison of gnome system settings and cinnamon system settings side by side

comparison of gnome system settings and cinnamon system settings

Applicaion window open in the right is Gnome settings application and any changes you make through here is not of any use, unless you are running Gnome desktop. Window shown in the right is the cinnamon system settings application and this is where you have to make your changes if are running default Linux Mint Cinnamon desktop.

Here is a comparison of how touchpad settings looks in both Gnome and Cinnamon settings applications.

comparison of cinnamon and gnome touchpad settings

Cinnamon system settings is easily distinguishable from Gnome settings by the fact they have a “switch to advanced/normal mode” link at the bottom of the application screen. Finally, the link has found some way of being actually useful 😉

gnome-control-centre is the application responsible for Gnome system settings, it has a lot of dependent applications, that removing the application will mess with your system, unless you know what  you are doing. So, if you are not absolutely sure what you are doing, I’ll ask you to not remove it.

Tip for the day – Fix your terminal displaying junk characters

August 24, 2013 Leave a comment

Sometimes when reading a binary file your terminal font may be set to junk values and whatever you type will appear as junk. This may happen when reading a binary file through cat command, opening the raw device files like /dev/random /dev/urandom, or reading  /proc/kcore memory file. Below screen shot shows how terminal looks when this happens,

Terminal displaying all characters as garbage after reading a binary fileWhen you are working in GUI environment within a terminal emulator this may not be a problem as you can close and reopen a new terminal. But this is a problem when you’re working in text environment.

There is an easy way to fix this problem by resetting the terminal. Yes typing reset command in the terminal will reset your terminal back to normal state.

stumbled across a new bug with notifications in cinnamon desktop

March 30, 2013 Leave a comment

When applications are running in full screen, notifications does not appear in cinnamon desktop. When running applications in full screen like watching a movie in media player, viewing firefox in full screen and if there is any notification bubbles appearing it doesn’t show up. It only appears below the full screen application. Whatever be the criticality of the notification it doesn’t appear. This could lead to many problems like not getting to know when the battery is getting low, when disconnected from a network etc.

Ideally notifications should appear on top of whatever application the user is running, but this is not the case.

This bug could be reproduced by running the command notify-send in terminal as given below,

sleep 10 ; notify-send hi

and run an application in full screen and wait for 10 secs and check whether ‘hi’ appears. If it doesn’t appear, you are affected by this bug.

I have reported this bug in launchpad linux mint page here:

If you can reproduce this go and subscribe to this bug by clicking ‘Yes,this bug affect me’  in the bug page.

Power management issue with Linux desktops

March 15, 2013 2 comments

Power management in Linux mint desktop does not kick in when the system is booted upon, it only starts up when the cinnamon desktop is logged into. This should not be the case because when the system is powered up and left untouched, the brightness settings does not work, battery management settings doesn’t work. When this is the case battery gets drained completely.

By default in power manager settings, system is configured to take critical battery action only when 2 minutes of power is remaining. Thus most people wouldn’t have noticed the seriousness of this problem. I configured my system to take critical battery action when battery is at 25 % by modifying the dconf-editor settings and confirming this is the case.

I have reported a bug to Linux mint in launchpad here

If you are facing this bug, please add a comment against this bug.

I’m afraid this is how gnome3 desktop behaves too. This must affect all the linux distributions using cinnamon and gnome3 desktop. At this moment i have no idea what are all the distributions affected. If your version of linux is affected, please report it to your distributions authors at the appropriate place.

I guess this is more of a design error than of a bug

Easy way to fix script errors that occur when scheduled with cron

February 4, 2013 Leave a comment

Some scripts that work fine when run manually in a shell environment will just fail when scheduled with cron. This is due to shell environment variables not available to those scripts when cron executes the scripts. You can verify this by running env or printenv commands in both the shell in which you manually execute the script and in cron by schedule it to the nearest minute and writing it to a file.

# m h  dom mon dow   command
35 * * * * env > /tmp/env.log

By comparing both outputs you can find that the environment variables available in cron are very limited.

Most errors will arise due to commands in your script not available in location set by cron environment PATH variable. You can compare the value of PATH variable in both outputs and tell that the executable paths cron looks in is very limited. You can fix this by giving the full path to commands in your shell script, but you have to look for where the executables are located and modify all those scheduled scripts.

However there is one easy fix to this problem. The important thing to note is cron allows you to set environment variables in the crontab file. So you could just add the variables you wanted to be available to cron at the top of the crontab file as shown below.

# m h  dom mon dow   command
38 * * * * env > /tmp/env.log

Now schedule the script again and check the output of /tmp/env.log file. You can see that the values you passed were availabe to cron. By this way you can run those scripts just the way it is without any modifications.

configure battery power settings in Gnome

January 25, 2013 Leave a comment

Gnome desktop does not allow users to set the values for battery critical state, Power settings will only allow users to set what action is to be taken when the battery is critical. By default it is considered critical when battery backup time is  5 minutes and it will initiate battery critical action when backup time remaining is 2 minutes. This default behavior is questionable because 2 minutes will not be sufficient for all users to find a power source and as most batteries used today are lithium-ion batteries, their life will get significantly reduced by this default behavior when drained so low so often.

Fortunately, this can be changed in configuration editor. systems using older Gnome versions such as Gnome2 desktops had a tool called Gconf-editor to change these configuration settings. Newer Gnome versions such as systems using Gnome3 desktop use a tool called dconf-editor to make changes to these configuration settings.Install this tool by using below command from terminal

sudo apt-get install dconf-editor

After installing open dconf-editor and look for following path in the left pane



In the right pane look for the fields,




and change the time values for the fields according to your preferences.Note that the time is defined in seconds.

Description for the fields and the type of value it accepts will be available at the bottom pane, when you select the fields.

Alternatively, if you want your system to consider the battery percentage instead of remaining time, uncheck the key


and modify the keys




to your preference.Now your system should take the values you defined after the next boot or restart your system for the settings to take effect immediately.