Resolving the "bin/sh: 1: source not found" Error – A Linux Coder‘s Guide

The "bin/sh: 1: source not found" message can be one of the most frustrating to debug for Linux developers and sysadmins. But having a clear understanding of what causes this cryptic error message, and the various ways to resolve it, are key skills for any professional working with Bash or other shells.

In this comprehensive guide, we‘ll share insider techniques and research to demystify the source not found error, trace why and how it emerges, and empower you to solve it swiftly when coding or administering any Linux system.

The Crucial Role of Source in Bash and Other Shells

The source command available in Bash, ksh, csh, and other shells plays an important role in scripting on Linux, UNIX, and POSIX systems. What exactly does it do?

At its foundation, source loads another script or file into the current shell. This allows you to import exportable variable definitions, functions, aliases, and other elements defined in the sourced file so you can access them in the current shell.

Here is a common example usage:

# Load bash alias and function definitions from bashrc
source ~/.bashrc

Or with Python virtual environments:

# Activate the virtual env by sourcing its activation script
source ~/envs/myenv/bin/activate 

The source command operates at the shell level by evaluating the given file within the current shell process itself. This also means that any code executed by the file will alter the current shell environment directly.

This is extremely convenient functionality. But as we‘ll explore next, over-reliance on source-ing files can backfire outside of Bash.

Why "Source not Found"? Bash vs Sh Compatibility Pitfalls

The "source not found" error arises because source is actually not a universally supported command across all shells.

It is specifically a built-in command included in:

• Bash – GNU Bourne Again SHell
• ksh – Korn SHell
• csh – C SHell

However, source is not natively recognized in the original Bourne shell (/bin/sh) or alternatives like Dash and Almquist shell used on many modern Linux distributions.

Here‘s a breakdown of the shell landscape across some common Linux distributions:

Distribution	/bin/sh Default Shell	Built-in Source Support
Ubuntu/Debian	Dash (/bin/dash)	No
RHEL/CentOS	Bash (/bin/bash)	Yes
Arch Linux	Bash	Yes
Alpine Linux	Almquist Shell	No

So the error arises when you attempt to run source on a system where:

1. /bin/sh points to something other than Bash by default (Dash in Ubuntu‘s case)
2. And this alternative shell has not implemented source as a built-in command.

This explains why developers often encounter the error running Bash scripts on Ubuntu but not on CentOS, for example.

Technical Dive – How Source Leverages Shell Inheritance

To truly master resolving this error, we need to dive deeper into how source leverages Linux‘s standard streams and the shell execution hierarchy:

On any Linux system, running a script or executable follows this inheritance chain:

1. A parent process runs, forking a new child process
2. The parent‘s stdin/stdout/stderr handles get inherited by the child
3. So the child can access the parent‘s terminal sessions and streams

This flow allows piping commands together so one feeds into the next.

Understanding this, the source shell command works by:

1. Loading code from a file
2. And evaluating this code within the "parent" shell process itself rather than spawning a new child process.

This gives the imported code access to modify the current shell environment variables, functions etc.

However, calling source from a Bash script under /bin/sh instances Dash/Almquist instead of Bash itself. So the command fails since Dash and other sh shells have not implemented it.

Ultimately, over-reliance on source-ing files leads to shell dependency issues. But avoiding it entirely also has trade-offs we‘ll explore next.

Resolving Approaches – When and How to Apply Them

With the root cause uncovered, let‘s dig into actionable solutions. We‘ll provide specific recommendations on optimal approaches based on common use case scenarios.

Using "." Instead of "source"

The simplest fix in many cases will be using . file rather than source file:

. ~/.bashrc

This works because . serves as a portable alias for the source built-in across POSIX-compliant shells. So . avoids the command missing error.

In particular, . can substitute source safely when running:

• Bash scripts – Use . rather than source so they work under /bin/sh
• Virtualenv activation scripts – Already often do this – making them more compatible

However, . is not 100% identical to source. It spawns a new subprocess, so modifications to shell internals don‘t persist after. This causes issues sourcing certain special startup files mid-session.

So while . works in many cases, it still has limitations vs source depending on context.

Invoking Scripts Under Bash Explicitly

Calling scripts under Bash directly instead of /bin/sh avoids reliance on sh shells entirely:

#!/bin/bash

# Will work fine now even with source  
source ~/.bashrc

However, this reduces some cross-shell portability. Tradeoffs exist between convenience via source and compatibility.

Developers must balance these considerations when building scripts and tooling intended for wide distribution.

Reconfiguring the System Shell

Some Linux administrators attempt resolving this by reconfiguring /bin/sh to point to Bash instead:

sudo dpkg-reconfigure dash # Ubuntu/Debian 
sudo chkconfig --del dash # RHEL/CentOS

However, this can risk breaking compatibility with scripts coded against Dash or strict POSIX shell features only. So blindly switching the default system shell is generally not recommended without thorough testing.

Refactoring Code to Avoid Needing Source

The most robust, but also most work intensive solution is refactoring code to remove reliance on source entirely.

Some common techniques include:

• Export reusable variables to a separate file, then source that file only under bash using .
• Define functions internally within scripts rather than externally sourcing them
• Use exec rather than source to import external functionality more safely

Assuming source usage is unavoidable, isolating it only to explicitly bash-invoked scripts or bootstrapping logic can contain the portability impact.

Additional Compatibility Considerations

While . vs source accounts for most resolution approaches, further technical factors can also contribute to source errors.

For example, some Python virtual env scripts add this line allowing them to work regardless:

COMMAND_NOT_FOUND_HANDLE=source

Rather than source directly, this handles command missing errors gracefully – improving overall robustness.

Sourcing startup files can also behave differently mid-session depending on their contents and whether child processes get spawned.

So knowledge of shell process inheritance, and other Linux/UNIX intricacies can optimize usage.

Conclusion – Mastering Source and Its Alternatives

Like any specialized tool, source streamlines tasks remarkably when used properly – but also risks issues when overapplied blindly.

Internalizing its implementation tradeoffs across Bash, Dash, and POSIX shells will equip you to troubleshoot and resolve source errors seamlessly.

Beyond that, mastery of approaches like . vs source, containment strategies, and rebootstrapping flows will optimize your shell scripting practices.

By taking time to deeply internalize these concepts rather than just copying boilerplate scripts, you can enhance your versatility administering any Linux environment.

The source command has traditionally been called a "Swiss army knife" for its flexibility. I hope this guide has helped unlock and sharpen this tool in your own toolkit!