Productivity with Bash

Chapters 13 and 14 showed how Bash cleans up files, creates backups, and manages photo/video collections automatically. This chapter takes a slightly different direction: it is no longer about processing files, but about making the daily workflow of users on the desktop more streamlined. Busy users context-switching between many applications often forget to record small reminders or have to manually copy their favorite configurations one by one when moving to a new laptop. Reminders that pop up automatically without needing to be remembered, text snippets copied directly to the clipboard without retyping, and even a brand new laptop ready to use just by running a single script are all perfect tasks to delegate to Bash. This chapter covers four topics: simple reminders and notifications via notify-send and cron, integration with desktop applications such as clipboards and screenshots, building "dotfiles" to store personal configurations, and closing with a case study combining everything into a single new laptop setup script.

15.1 Simple Reminders and Notifications

This section covers how to trigger desktop notifications from a script, then schedule them to appear automatically at specific times without manual execution.

15.1.1 Desktop Notifications with notify-send

notify-send is a command-line tool for displaying popup notifications on the desktop, part of the libnotify library that implements the Desktop Notifications Specification from freedesktop.org. This tool has become the de facto standard in modern Linux desktop environments using D-Bus, including GNOME, KDE Plasma, and most window managers that enable a notification daemon.

notify-send "Backup Complete" "Documents folder has been backed up."

The first argument is the notification title, while the second argument is the message body. Several additional options are useful for configuring notification behavior: -u sets the urgency level (low, normal, or critical), and -i specifies the icon to display.

notify-send -u critical -i dialog-warning "Disk Almost Full" "Remaining space on / is down to 5%."

Notifications with critical urgency usually do not expire automatically in many notification daemons, making them suitable for alerts that genuinely require attention, such as a nearly full disk or a failed backup process. It should be noted that notify-send is not installed by default in all distributions; on Debian/Ubuntu it comes via the libnotify-bin package, whereas on Fedora and Arch Linux the package name is simply libnotify. If the notify-send command is not found, install it first using the appropriate package manager.

# Debian/Ubuntu
sudo apt install libnotify-bin

# Fedora
sudo dnf install libnotify

# Arch Linux
sudo pacman -S libnotify

In practice, notify-send sometimes outputs nothing even though the command runs successfully without errors. The most common cause: the script is executed via cron or from an ssh session not connected to the active desktop session, leaving the notification unaware of which screen to display on. This issue and its solution are discussed further in section 15.1.3.

15.1.2 Scheduling Reminders with Cron

Manual notifications are only useful if someone runs them. To ensure reminders appear automatically at designated times without manual intervention, combine notify-send with cron, a task scheduler daemon available in almost all Linux distributions as well as macOS. Chapter 18 delves deeper into cron and systemd timer for server scheduling needs; here the focus is specifically on personal reminders for regular users without root privileges.

Every user has their own crontab, edited via crontab -e without needing sudo. This command opens the default text editor defined by the EDITOR environment variable mentioned in Chapter 3.2.3.

crontab -e

A single crontab line consists of five time columns followed by the command to execute.

0 9 * * 1-5 notify-send "Standup Time" "Don't forget to join standup at 9 AM."

These five columns, in order, are minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 represents Sunday). The line above means "run every day at 9 AM, from Monday through Friday (1-5)". Once saved, verify active crontab entries using crontab -l.

crontab -l

15.1.3 Troubleshooting: Cron Notifications Not Appearing

The most frequent pitfall users encounter when combining cron with notify-send: notifications never appear, even though the crontab line is correct and cron logs confirm successful execution. The reason is that cron processes run in an isolated session that does not inherit environment variables from the active desktop session, specifically DISPLAY and DBUS_SESSION_BUS_ADDRESS, two variables required by notify-send to determine which graphical session to deliver notifications to. This is a direct consequence of environment variable scoping covered in Chapter 3.2: child processes only inherit exported variables, and cron processes are not children of the desktop session, so they do not receive either variable automatically.

The standard solution is explicitly defining both variables inside the crontab, retrieving their values from the running desktop session.

0 9 * * 1-5 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send "Standup Time" "Don't forget to join standup at 9 AM."

The value /run/user/1000/bus assumes the user ID (UID) is 1000, the standard UID for the initial user created on most Linux systems, but this should still be verified using the command id -u prior to use, as UIDs may vary depending on account creation order. If reminders still fail to appear after appending these variables, the notification daemon in the active desktop environment may not be running or may use a different mechanism; verify first by running notify-send directly from a terminal within the same desktop session as a benchmark.

15.2 Integration with Desktop Applications

This section explains how Bash interacts with two desktop features commonly used in daily automation: the clipboard and screenshots, along with critical notes regarding tool differences across display servers.

15.2.1 X11 vs Wayland: Why Tools Differ

Tools for accessing the clipboard or capturing screenshots from the terminal are not uniform across all Linux distributions because they depend on the underlying display server. The two most common display servers today are X11 (legacy, still widely used) and Wayland (newer, default on many modern distributions like recent Ubuntu and Fedora releases). Each tool in this section clearly indicates its supported display server, as X11 tools generally do not function in pure Wayland sessions and vice versa. The fastest way to determine which session is currently active is checking the XDG_SESSION_TYPE variable.

echo "$XDG_SESSION_TYPE"

15.2.2 Accessing the Clipboard from Scripts

In X11 sessions, the two most common tools for reading and writing the clipboard from the terminal are xclip and xsel. Both must be installed separately via the package manager as they are not part of Xorg or Bash itself.

# Debian/Ubuntu
sudo apt install xclip

# Fedora
sudo dnf install xclip

# Arch Linux
sudo pacman -S xclip

echo "Text to copy" | xclip -selection clipboard
xclip -selection clipboard -o

The -selection clipboard option must be specified explicitly because X11 maintains multiple distinct clipboards simultaneously (primary, secondary, and clipboard). Without this option, xclip defaults to the primary selection, which only holds recently highlighted text rather than the standard clipboard accessed by Paste (Ctrl+V). The -o (output) flag reads clipboard contents to stdout so it can be captured via command substitution (Chapter 3.4.4) or piped to other tools (Chapter 5.3.5).

In Wayland sessions, xclip will not function. Its counterpart is wl-clipboard, which provides two dedicated utilities: wl-copy and wl-paste.

# Debian/Ubuntu
sudo apt install wl-clipboard

This package name is identical on Fedora (sudo dnf install wl-clipboard) and Arch Linux (sudo pacman -S wl-clipboard), following the three-distro pattern detailed in 15.1.1.

echo "Text to copy" | wl-copy
wl-paste

On macOS, clipboard integration is far simpler because the operating system provides pbcopy and pbpaste natively out of the box without requiring additional installation.

echo "Text to copy" | pbcopy
pbpaste

A practical case study: copying the current working directory path straight to the clipboard, a useful workflow when moving between project directories.

pwd | xclip -selection clipboard

15.2.3 Screenshots from the Terminal

Automated screenshot tools are similarly divided between X11 and Wayland. On X11, scrot is one of the lightest and most common command-line utilities available.

# Debian/Ubuntu
sudo apt install scrot

Like other packages in this chapter, the package name scrot is consistent across Fedora (dnf install scrot) and Arch Linux (pacman -S scrot).

scrot ~/Pictures/screenshot-"$(date +%Y%m%d-%H%M%S)".png

The pattern date +%Y%m%d-%H%M%S matches the unique naming technique used for backup archives in Chapter 13.2.3, ensuring every screenshot receives a unique filename even when executed rapidly in succession.

In Wayland sessions, scrot fails due to Wayland security architecture restrictions that block direct access to other applications' screen buffers. The appropriate tool depends on the active compositor; for wlroots-based compositors like Sway, grim is standard, sharing the same package name across Fedora and Arch Linux repositories.

# Debian/Ubuntu
sudo apt install grim

grim ~/Pictures/screenshot-"$(date +%Y%m%d-%H%M%S)".png

GNOME and KDE Plasma running on Wayland use proprietary screenshot mechanisms via their respective D-Bus interfaces, which may not be compatible with grim; if using one of these desktop environments, consult its official documentation for natively supported terminal screenshot commands. On macOS, screencapture comes preinstalled without requiring additional software.

screencapture ~/Pictures/screenshot-"$(date +%Y%m%d-%H%M%S)".png

15.3 Building Dotfiles

This section discusses managing personal configuration files, commonly called dotfiles because their names start with a dot like .bashrc or .gitconfig, making them easy to transfer to new systems or restore after OS reinstallation.

15.3.1 Why Dotfiles Should Be Managed with Git

Configuration files such as .bashrc, .gitconfig, and .vimrc accumulate years of user customizations: favorite aliases (Chapter 13.4), custom shell functions, editor settings, and preferences whose value is rarely realized until lost during a system reinstallation or hardware migration. Storing dotfiles inside a Git repository, standard practice in open-source communities as covered under script versioning in Chapter 26.3, keeps configuration history tracked and easily restorable across any system.

15.3.2 Dotfiles Structure and Symlinks

The standard approach: group all dotfiles into a dedicated repository folder, then create symbolic links pointing from their original locations (e.g., ~/.bashrc) to the files inside the repository. Editing files in the repository automatically updates the active configuration, allowing changes to be committed cleanly.

mkdir -p ~/dotfiles
mv ~/.bashrc ~/dotfiles/bashrc
ln -s ~/dotfiles/bashrc ~/.bashrc

ln -s creates a symbolic link rather than copying the file. After running this command, ~/.bashrc acts as a shortcut pointing to ~/dotfiles/bashrc, keeping their contents identical. For extensive dotfile setups, running mv followed by ln -s for every file becomes tedious; GNU Stow automates this symlink pattern based on structured directory layouts.

# Debian/Ubuntu
sudo apt install stow

The package name stow is identical on Fedora and Arch Linux.

cd ~/dotfiles
stow bash

According to official GNU Stow documentation, stow bash reads the bash/ directory inside the dotfiles repository and creates relative symlinks for each file inside it into the parent directory above the repository (in this case, $HOME), preserving directory hierarchy. This layout allows organizing dotfiles per application, such as separate bash/, git/, and vim/ folders, while linking everything via single commands.

15.3.3 Writing Idempotent Dotfiles Installation Scripts

To avoid repeating manual setup steps on new machines, wrap the installation logic into a single deployment script. Applying idempotent design principles ensuring safe, repeated execution without unintended side effects is essential here and is explored in detail in Chapter 23.2.

#!/bin/bash
set -euo pipefail

DOTFILES_DIR="$HOME/dotfiles"

if [[ ! -d "$DOTFILES_DIR" ]]; then
    git clone https://github.com/username/dotfiles.git "$DOTFILES_DIR"
fi

cd "$DOTFILES_DIR"

for target in bash git vim; do
    stow -v "$target"
done

set -euo pipefail on line two applies strict error handling options detailed in Chapter 25.1, causing the script to exit immediately if any command fails rather than continuing execution in an invalid state. The conditional [[ ! -d "$DOTFILES_DIR" ]] ensures git clone only executes if the repository directory is missing, allowing safe re-runs without triggering "destination path already exists" errors from Git. Per GNU Stow documentation, stow is naturally idempotent as long as existing symlinks already target the correct destinations, only reporting conflicts if an actual file (not a symlink) obstructs target paths.

15.4 Case Study: One-Shot New Laptop Setup

A common user scenario: unboxing a new laptop and spending hours re-installing applications and restoring old configurations individually before the environment is ready for work. This closing case study combines techniques from previous sections into an automated deployment script: installing essential packages, restoring dotfiles, and enabling default reminders in a single run.

15.4.1 Setup Script Design

A setup script for a new system has unique requirements compared to scripts in prior chapters: it must execute on a completely bare system before custom tools are installed, and ideally run across multiple Linux distributions. Consequently, the script must identify the running distribution before selecting the appropriate package manager, using a case statement (Chapter 6.3) combined with /etc/os-release, the standard freedesktop.org file available on virtually all modern Linux distributions.

15.4.2 Complete Script Implementation

#!/bin/bash
set -euo pipefail

DOTFILES_DIR="$HOME/dotfiles"
DOTFILES_REPO="https://github.com/username/dotfiles.git"

# 1. Detect distribution and install essential packages
if [[ -f /etc/os-release ]]; then
    . /etc/os-release
else
    echo "Unable to detect distribution, exiting." >&2
    exit 1
fi

case "$ID" in
    ubuntu|debian)
        packages=(git curl vim tmux stow libnotify-bin xclip)
        sudo apt update
        sudo apt install -y "${packages[@]}"
        ;;
    fedora)
        packages=(git curl vim tmux stow libnotify xclip)
        sudo dnf install -y "${packages[@]}"
        ;;
    arch)
        packages=(git curl vim tmux stow libnotify xclip)
        sudo pacman -Sy --noconfirm "${packages[@]}"
        ;;
    *)
        echo "Distribution '$ID' is not supported by this script." >&2
        exit 1
        ;;
esac

# 2. Clone and deploy dotfiles
if [[ ! -d "$DOTFILES_DIR" ]]; then
    git clone "$DOTFILES_REPO" "$DOTFILES_DIR"
fi

cd "$DOTFILES_DIR"
for target in bash git vim; do
    stow -v "$target"
done

# 3. Weekly configuration review reminder
( crontab -l 2>/dev/null; echo "0 9 * * 1 notify-send 'Review Dotfiles' 'Check dotfiles updates for this week.'" ) | sort -u | crontab -

echo "Laptop setup complete."

The line . /etc/os-release uses shell sourcing (Chapter 13.4.2) to import environment variables directly from the file, including the lowercase ID variable (such as ubuntu, fedora, or arch) defined by freedesktop.org specifications. The case "$ID" block selects package manager commands tailored to the OS, using *) as a fallback branch if the OS is unsupported. The packages array (Chapter 4.1) is deliberately defined inside each case branch rather than globally, because package names differ across distributions: libnotify-bin is Debian/Ubuntu-specific, whereas Fedora and Arch Linux provide the utility under the package name libnotify. Overlooking package naming differences when sharing lists across distributions leads to installation failures mid-execution.

Because stow is installed in step 1 and set -e halts execution on command failures, step 2 safely executes stow without secondary checks. The final block appends a new crontab schedule from 15.1.2 while preserving existing entries: crontab -l 2>/dev/null reads active schedules (suppressing errors if no crontab exists), pipes the new schedule line, deduplicates via sort -u, and applies the combined result to crontab -. This append pattern avoids invoking interactive crontab -e within automated scripts without overwriting pre-existing user jobs. Note that 2>/dev/null also hides errors unrelated to missing crontab files; if reminders fail to register, execute crontab -l directly without redirection to view diagnostic messages.

15.4.3 Verification and Next Steps

Following script execution, verify deployment across three key areas: confirm binary installations with command -v git curl vim tmux, inspect active dotfile symlinks using ls -la ~ | grep dotfiles, and review scheduled crontab jobs with crontab -l.

command -v git curl vim tmux
ls -la ~ | grep dotfiles
crontab -l

This baseline setup script can be expanded further by incorporating a --dry-run flag as covered in Chapter 13.1.4 to preview package installations prior to execution, or by adding user prompt validations before invoking sudo apt install automatically. The core productivity topics covered in this chapter notifications, desktop integration, dotfile management, and system bootstrapping round out everyday desktop automation using Bash. Chapter 16 explores shell customization, ranging from interactive prompt configuration to building portable cross-system dotfile environments.