mkdir at a time or hunting for PIDs with ps and grep wastes time on every server you manage. Here’s how mkdir -p, heredocs, tar -C, pkill, and pidwait can simplify these tasks with fewer commands.After extraction, the Go binaries are available in /usr/local/go/bin, even though you never changed your working directory:
wget https://go.dev/dl/go1.25.3.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.25.3.linux-amd64.tar.gz
go1.25.3 with the appropriate version listed on the official website site./home/tecmint/myapp
├── bin
├── config
│ ├── nginx
│ └── systemd
├── data
│ ├── backups
│ ├── cache
│ └── uploads
├── logs
└── scripts
10 directories, 0 files
Preview Brace Expansion Before Creating Directories
command -v pidwait
echo ~/myapp/{bin,config/{nginx,systemd},logs}
For example:
sudo mkdir -p /opt/node
sudo tar -xf node-v24.11.0-linux-x64.tar.xz -C /opt/node –strip-components=1
Here’s how Bash expands the braces in this command:
sudo dnf install zstd
Common Mistakes with tar -C
Once the directories are in place, the next step is usually to create a configuration file. The traditional approach involves creating the file, opening it in an editor, entering the content, and saving it. That works well for occasional tasks, but it becomes tedious when you’re configuring multiple servers or automating deployments.
Once the directories are in place, the next step is usually to create a configuration file. The traditional approach involves creating the file, opening it in an editor, entering the content, and saving it. That works well for occasional tasks, but it becomes tedious when you’re configuring multiple servers or automating deployments.
Once the directories are in place, the next step is usually to create a configuration file. The traditional approach involves creating the file, opening it in an editor, entering the content, and saving it. That works well for occasional tasks, but it becomes tedious when you’re configuring multiple servers or automating deployments.
Once the directories are in place, the next step is usually to create a configuration file. The traditional approach involves creating the file, opening it in an editor, entering the content, and saving it. That works well for occasional tasks, but it becomes tedious when you’re configuring multiple servers or automating deployments.
Once the directories are in place, the next step is usually to create a configuration file. The traditional approach involves creating the file, opening it in an editor, entering the content, and saving it. That works well for occasional tasks, but it becomes tedious when you’re configuring multiple servers or automating deployments.
/home/tecmint/myapp/bin /home/tecmint/myapp/config/nginx /home/tecmint/myapp/config/systemd /home/tecmint/myapp/logs
Brace Expansion Doesn’t Work in /bin/sh Scripts
For example, this command fails for a regular user who lacks permission to write to the destination:
The second category includes command options, such as tar -C and the process-matching options available in pgrep and pkill. These are implemented by the respective utilities rather than by the shell, so their behavior doesn’t depend on which shell launches them.
You may see older examples that use pkill apache2 to stop a web server. For services managed by systemd, however, the recommended approach is to use systemctl stop.
python3 killed (pid 4821)
A simpler approach is to use pgrep to find processes and pkill to signal them by name or command-line pattern.
We’d love to hear which of these tips you already use and which one is new to you. Do you have your own one-liner that replaced a long routine on your servers?
On Ubuntu and Debian:
tree ~/myapp
If you’d like to build more habits like these, our 100+ Essential Linux Commands course on Pro TecMint covers the everyday commands sysadmins rely on with practical examples.
/opt just to extract them, share this with a teammate who still does the same.4. Find and Kill Processes by Name with pgrep and pkill
Before using pkill with a broad pattern, preview the matches with pgrep -a using the same pattern and relevant filters. This helps you identify the processes that could be affected before sending a signal.
pkill -e -f “http.server”
In this guide, we’ll explore five practical techniques that replace repetitive, multi-step routines with simpler commands. We’ve tested the examples on Ubuntu 26.04 LTS and Rocky Linux 10. They should also work on other Linux distributions, unless a section notes otherwise.
cat ~/myapp/config/app.env
On Ubuntu and Debian, the Apache service is named apache2:
sudo cat << ‘EOF’ > /etc/sysctl.d/90-tecmint.conf
vm.swappiness = 10
EOF
A common workaround is a while loop that repeatedly checks for the process with pgrep and pauses with sleep. The pidwait command, provided by the procps-ng package, offers a simpler alternative by waiting for matching processes to terminate.
The traditional approach is to run multiple mkdir commands, one for each directory. A quicker approach combines mkdir -p with Bash brace expansion to create the entire directory tree in a single command:
The final tip builds on pgrep and pkill but solves a different problem: waiting for a process to finish before running the next command. For example, you might want to start a package upgrade only after a long-running backup has completed.
-fmatches against the full command line instead of just the process name. Use it when multiple programs share the same executable name, but make sure your pattern identifies only the intended process.-xrequires an exact match for the process name. For example,pkill -x sshmatches a process namedssh, not one namedsshd.-u tecmintrestricts the search to processes owned by thetecmintuser, helping avoid unintended matches on shared servers.-HUPor--signal HUPsends SIGHUP instead of the default SIGTERM. SIGTERM requests a graceful shutdown, whereas SIGKILL (-9) forcibly terminates a process without giving it an opportunity to clean up.
Let’s start a small test process so you can practise safely. Python’s built-in HTTP server is available on both Ubuntu and Rocky Linux, and the & operator runs it in the background:
Stop System Services with systemctl Instead of pkill
while pgrep -x rsync > /dev/null; do
sleep 5
done
echo “Backup finished at $(date +%T)”
cat << EOF > ~/myapp/DEPLOYED.txt
Deployed by: $USER
Host: $(hostname)
Date: $(date +%F)
EOF
You now have five commands that each replace a multi-step routine: mkdir -p with brace expansion for directory trees, heredocs with cat or sudo tee for files, tar -C for extracting archives anywhere, pgrep and pkill for finding and stopping processes by name, and pidwait for running a command once a process finishes. Each one makes your scripts shorter and removes chances for a typo along the way.
Once the application directories and configuration files are ready, the next step is often installing software distributed as a tarball. A common approach is to move the archive to its destination, change into that directory, and extract it. Alternatively, you might extract it in ~/Downloads and move the resulting directory afterward. Both approaches involve unnecessary steps.
Eventually, you’ll need to stop a running process, whether it’s a test server, a stuck script, or an application that’s no longer responding. The traditional approach is to run ps -A | grep -i apache2, identify the relevant PIDs, and pass them to kill manually. Although this works, it takes extra steps and can produce confusing results when `grep` matches its own command line.
5. Wait for a Process to Finish with pidwait
sudo apt install -y tree
mkdir: created directory ‘/home/tecmint/myapp’
mkdir: created directory ‘/home/tecmint/myapp/bin’
mkdir: created directory ‘/home/tecmint/myapp/config’
mkdir: created directory ‘/home/tecmint/myapp/config/nginx’
mkdir: created directory ‘/home/tecmint/myapp/config/systemd’
mkdir: created directory ‘/home/tecmint/myapp/logs’
mkdir: created directory ‘/home/tecmint/myapp/data’
mkdir: created directory ‘/home/tecmint/myapp/data/uploads’
mkdir: created directory ‘/home/tecmint/myapp/data/cache’
mkdir: created directory ‘/home/tecmint/myapp/data/backups’
mkdir: created directory ‘/home/tecmint/myapp/scripts’
These habits aren’t wrong, but they add unnecessary steps. Across multiple servers, those extra commands add up. They also make shell scripts longer and introduce more opportunities for typos.
For heredocs in scripts, quote the marker (<< 'EOF') unless you specifically need variable expansion. An unquoted heredoc that contains a $ meant for the config file, such as a password or a Nginx variable like $host, gets silently replaced with an empty string, and the result is a config file that looks fine but doesn’t work.
A heredoc (short for here document) lets you pass multiple lines of text directly to a command using a designated closing marker. Combined with cat and output redirection, it creates a file and writes its contents in one step.
Before extracting an unfamiliar archive, inspect its contents to understand its directory structure:
On Ubuntu and Debian, run:
ls /usr/local/go/bin
sudo systemctl stop apache2
One important detail is that pidwait waits for processes it successfully identifies when it starts. If no matching process exists, it returns immediately rather than waiting for a future rsync process to appear. Also, matching by process name alone can be ambiguous if multiple rsync processes are running.
4821 python3 -m http.server 8000
Before diving into the examples, it’s worth understanding that these techniques fall into two categories: shell features and command options. Knowing the difference helps explain how they behave, especially in scripts.
sudo tee /etc/sysctl.d/90-tecmint.conf > /dev/null << ‘EOF’
vm.swappiness = 10
EOF
Heredocs are also useful for creating system configuration files under directories such as /etc. However, a common mistake is to assume that prefixing a command with sudo also grants elevated permissions to its output redirection.
Conclusion
mkdir -pv ~/myapp/{bin,config/{nginx,systemd},logs,data/{uploads,cache,backups},scripts}
The first category includes shell features, such as brace expansion and heredocs, Bash handles these before executing a command.
cat ~/myapp/DEPLOYED.txt
As a result, a script beginning with #!/bin/sh may pass an expression such as {bin,config} to mkdir literally instead of expanding it into separate directory names.
sudo dnf install -y tree
Once installed, display the directory structure:
