Skip to content

Both.org

News, Opinion, Tutorials, and Community for Linux Users and SysAdmins

Primary Menu
  • About Us
  • Computers 101
    • Hardware 101
    • Operating Systems 101
  • End of 10 Events
    • Wake Forest, NC, — 2025-09-20
  • Linux
    • Why I use Linux
    • The real reason we use Linux
  • My Linux Books
    • systemd for Linux SysAdmins
    • Using and Administering Linux – Zero to SysAdmin: 2nd Edition
    • The Linux Philosophy for SysAdmins
    • Linux for Small Business Owners
    • Errata
      • Errata for The Linux Philosophy for SysAdmins
      • Errata for Using and Administering Linux — 1st Edition
      • Errata for Using and Administering Linux — 2nd Edition
  • Open Source Resources
    • What is Open Source?
    • What is Linux?
    • What is Open Source Software?
    • The Open Source Way
  • Write for us
    • Submission and Style guide
    • Advertising statement
  • Downloads
  • Home
  • Parsing config files with Bash
  • Bash
  • Code
  • Linux
  • System Administration

Parsing config files with Bash

Separating config files from code enables anyone to change their configurations without any special programming skills.
David Both March 12, 2024 5 minutes read
The Bash logo

The Bash logo

1

Image by Opensource.com

Separating config files from code enables anyone to change their configurations without any special programming skills.

Keeping program configurations separate from code is important. It enables non-programmers to alter configurations without having to modify the program’s code. With compiled binary executables, that would be impossible for non-programmers because it not only requires access to source files (which we do have with open source programs) but also a programmer’s skill set. Few people have that, and most people don’t want to learn.

With shell languages such as Bash, source code access is available by definition since shell scripts are not compiled into binary formats. Despite that openness, it is not a particularly good idea for non-programmers to root around in shell scripts and alter them. Even knowledgeable developers and sysadmins can make accidental changes that cause errors or worse.

So placing configuration items into easily maintained text files provides separation and allows non-programmers to edit configuration elements without the danger of making unintentional changes to the code. Many developers do this for programs written in compiled languages because they don’t expect the users to be developers. For many of the same reasons, it also makes sense to do this with interpreted shell languages.

The usual way

As with many other languages, you can write code for a Bash program that reads and parses ASCII text configuration files, reads the variable name, and sets values as the program code executes. For example, a configuration file might look like this:

var1=LinuxGeek46
var2=Opensource.com

The program would read that file, parse each line, and set the values into each variable.

Sourcing

Bash uses a much easier method for parsing and setting variables called sourcing. Sourcing an external file from an executable shell program is a simple method for including the content of that file into a shell program in its entirety. In one sense, this is very much like compiled language include statements that include library files at runtime. Such a file can include any type of Bash code, including variable assignments.

As usual, it is easier to demonstrate than to explain. All the steps in this experiment can and should be performed as a non-root user.

First, create a ~/bin directory (if it does not already exist), and make it the present working directory (PWD). The Linux Filesystem Hierarchical Standard defines ~/bin as the appropriate place for users to store their executable files.

Create a new file in this directory. Name it main and make it executable:

[dboth@david bin]$ touch main
[dboth@david bin]$ chmod +x main

Add the following content to this executable file:

#!/bin/bash
Name="LinuxGeek"
echo $Name

And execute this Bash program:

[dboth@david bin]$ ./main
LinuxGeek
[dboth@david bin]$

Create a new file and call it ~/bin/data. This file does not need to be executable. Add the following information to it:

# Sourced code and variables
echo "This is the sourced code from the data file."
FirstName="David"
LastName="Both"

Add three lines to the main program so that it looks like this:

#!/bin/bash
Name="LinuxGeek"
echo $Name
source ~/bin/data
echo "First name: $FirstName"
echo "LastName: $LastName"

Rerun the program:

[dboth@david bin]$ ./main
LinuxGeek
This is the sourced code from the data file.
First name: David
LastName: Both
[dboth@david bin]$

There is one more really cool thing to know about sourcing. You can use a single dot (.) as a shortcut for the source command. Change the main file to substitute the . in place of source:

#!/bin/bash
Name="LinuxGeek"
echo $Name
. ~/bin/data
echo "First name: $FirstName"
echo "LastName: $LastName"

And run the program again. The result should be exactly the same as the previous run.

Starting Bash

Every Linux host that uses Bash—which is pretty much all of them since Bash is the default shell for all distributions—includes some excellent, built-in examples of sourcing.

Whenever a Bash shell starts, its environment must be configured so that it is usable. There are five main files and one directory that are used to configure the Bash environment. They are listed here along with their main functions:

  • /etc/profile: System-wide environment and startup programs
  • /etc/bashrc: System-wide functions and aliases
  • /etc/profile.d/: Directory that contains system-wide scripts for configuring various command-line tools such as vim and mc and any custom configuration scripts a sysadmin creates
  • ~/.bash_profile: User-specific environment and startup programs
  • ~/.bashrc: User-specific aliases and functions
  • ~/.bash_logout: User-specific commands to execute when the user logs out

Try to trace the execution sequence through these files and determine which sequence it uses for a non-login Bash initialization versus a log-in Bash initialization. I did this in Chapter 17 of Volume 1 in my Linux training series, Using and administering Linux: Zero to sysadmin.

I’ll give you one hint. It all starts with the ~/.bashrc script.

Conclusion

This article explored sourcing for pulling code and variable assignments into a Bash program. This method of parsing variables from a configuration file is fast, easy, and flexible. It provides a method for separating Bash code from variable assignments to allow non-programmers to set the values of those variables.

Tags: Bash Configuration

Post navigation

Previous: Convert your Windows install into a VM on Linux
Next: System statistics with sar and the /proc filesystem

Related Stories

f44-01-day-cropped
  • Fedora
  • Linux
  • Upgrades

Fedora 44 Released

David Both April 28, 2026
command_line_prompt
  • Command Line
  • Linux
  • Programming

Writing a replacement seq command

Jim Hall April 27, 2026
dark-web
  • Linux
  • News
  • Security
  • Vulnerability

High-severity Vulnerability in PackageKit

David Both April 25, 2026

Random Quote

The value of a program is proportional to the weight of its output.

— Laws of Computer Programming

Why I’ve Never Used Windows

On February 12 I gave a presentation at the Triangle Linux Users Group (TriLUG) about why I use Linux and why I’ve never used Windows.

Here’s the link to the video: https://www.youtube.com/live/uCK_haOXPFM 

Why there’s no such thing as AI

Last October at All Things Open (ATO) I was interviewed by Jason Hibbits of We Love Open Source. It’s posted in the article “Why today’s AI isn’t intelligent (yet)“.

Technically We Write — Our Partner Site

Our partner site, Technically We Write, has published a number of articles from several contributors to Both.org. Check them out.

Technically We Write is a community of technical writers, technical editors, copyeditors, web content writers, and all other roles in technical communication.

Subscribe to Both.org

To comment on articles, you must have an account.

Send your desired user ID, first and last name, and an email address for login (this must be the same email address used to register) to subscribe@both.org with “Subscribe” as the subject line.

You’ll receive a confirmation of your subscription with your initial password as soon as we are able to process it.

Administration

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

License and AI Statements

Both.org aims to publish everything under a Creative Commons Attribution ShareAlike license. Some items may be published under a different license. You are responsible to verify permissions before reusing content from this website.

The opinions expressed are those of the individual authors, not Both.org.

You may not use this content to train AI.

 

Advertising Statement

Both.org does not sell advertising on this website.


Advertising may keep most websites running—but at Both.org, we’re committed to keeping our corner of the web ad-free. Both.org does not sell advertising on the website. Nor do we offer sponsored articles at this time. We’ll update this page if our position on sponsorships changes.

We want to be open about how the website is funded. Both.org is supported entirely by David Both and a few other dedicated individuals.

 

 

Copyright © All rights reserved. | MoreNews by AF themes.