Process Logs and XML Data Using Bash (Part 31/34 )

I once had a cron job that quietly failed for three weeks straight because the script's bash logging xml parsing setup just printed to a terminal that nobody was watching. By the time anyone noticed, we had no record of what went wrong or when it started. That single missing habit, writing logs that actually survive after the script exits, cost more debugging time than the script itself took to write.

This guide is for anyone who already writes basic bash scripts and now needs them to produce logs you can trust and read XML data without losing your mind over angle brackets. By the end, you will be able to build a script that logs cleanly to a file, tags severity levels, and pulls values out of an XML file using tools made for that job instead of fragile regex.

Before diving into logging, it helps to understand how bash treats output streams in the first place. If you have not already gone through how echo works in shell scripts, that foundation will make the redirection tricks below click faster.

A lot of beginner scripts use echo for everything and call it logging. It is not. The moment that terminal session closes, every line of output is gone. Real logging means the message survives on disk, has a timestamp attached, and ideally tells you whether it was routine information or something that needs attention.

There is also a stream problem. Bash gives every script two separate output channels by default: standard output (stdout, file descriptor 1) and standard error (stderr, file descriptor 2). Most beginner scripts dump both into the same place, which means when something breaks you are stuck scrolling through hundreds of lines of normal output looking for the one error buried in the middle.

Notice the script kept going and printed "Backup finished" even though the command in the middle failed. The error message went to stderr, the success message went to stdout, and both landed in the same terminal with no way to tell which one mattered. That is the exact gap real logging closes.

The simplest real upgrade is a small function that wraps every message with a timestamp before printing it. You define it once near the top of the script and call it instead of echo everywhere else. This alone makes a script's output ten times more useful when you are reading it after the fact.

The $* inside the function grabs whatever text you pass when calling log, so the function stays generic instead of being tied to one message. Once you have this in place, the next step is sending that output somewhere that does not vanish when the terminal closes.

A single log function gets you timestamps but not severity. In production, you want to be able to grep a log file for just the errors without wading through every routine message. The fix is three small functions instead of one, with warnings and errors deliberately sent to stderr using >&2 so they can be filtered separately later.

Now you can run the script and send only the errors to one file and everything else to another with ./script.sh 2>errors.log 1>info.log. That single change is the difference between scrolling through hundreds of lines after an incident and running one grep command that shows you exactly what broke.

Level functions are great inside the script, but you still need the output to land on disk. The trick most production scripts use is exec combined with tee near the top of the file. This redirects the script's own output streams for the rest of its run, so every later command writes to both the screen and the log file automatically, with no extra typing needed at each line.

The 2>&1 at the end merges stderr into the same stream so nothing slips through unlogged, and giving every run its own timestamped filename means you never overwrite yesterday's log by accident. This pattern is exactly what you want for anything running unattended, including scripts triggered by cron jobs where nobody is watching the terminal in real time.

You can take this further by catching failures automatically with a trap, so the exact failing command gets written to the log even if you never expected that specific command to break.

If you have not worked with exit codes before, it is worth reading through bash exit codes and error handling alongside this, since traps and exit codes work together to make a script fail loudly instead of silently.

This is where a lot of people get into trouble. XML shows up everywhere in older enterprise systems, deployment manifests, and config exports, and the instinct is to grab the value with grep or sed since that is what you already know. It works fine on a clean sample file and then quietly breaks the day someone adds a line break or an attribute in a different order.

The tool built for this job is xmllint, which ships in the libxml2-utils package on most distributions. It understands XML structure instead of treating it as plain text, so it does not care about whitespace, attribute order, or line breaks the way grep does.

Say you have a config file listing servers, and you need a script to pull every IP address out of it automatically before running a health check loop. Here is the sample servers.xml file used for this example, followed by the script that reads it.

The --xpath flag returns the matching attribute including its quotes, so the grep right after it just peels the quotes off to give you a clean list of values. Piping that straight into a while read -r ip loop instead of storing it in a variable first avoids word-splitting issues if a hostname or value ever contains a space. For repeated work where you need to both query and rewrite XML, xmlstarlet is worth installing alongside xmllint since it adds editing and transformation on top of querying.

Here is the part that actually shows up in real bash logging xml parsing environments. You get a config in XML, you need to act on it, and you need a record of what happened. A common pattern is reading a list of services from an XML manifest, restarting each one, and logging every step to a file so the next person does not have to guess what ran. Here is the sample services.xml file that matches the log output below it.

If this runs from cron and one of those services has a typo in the manifest, the trap catches the failing systemctl command, logs exactly which service name was wrong, and the timestamped log file in ~/logs is sitting there waiting for you the next morning. No guessing, no recreating the failure by hand.

For debugging a script like this while you are still writing it, run it with bash -x script.sh once to see every command bash actually executes, variable expansions included. It is slower and noisier than the clean log output above, but it catches the kind of typo that a trap alone will not explain clearly.

Once a script logs to a timestamped file with severity levels baked in, you stop dreading the "it ran fine for me" conversation. You can hand a log file to a teammate and they can see exactly what happened without re-running anything. The trap pattern means failures point at the actual broken command instead of a vague exit code, which matters most at the worst possible time, during an incident at 3 AM.

The XML side matters for a different reason. A lot of infrastructure still ships config and inventory data in XML, and treating it as plain text with grep works right up until it does not, usually during a deploy you cannot easily roll back. Parsing it properly with xmllint or xmlstarlet means a reformatted file or an extra attribute does not quietly break your automation.

Once these two pieces are solid, the natural next step is wrapping the same logging pattern around bash scripting log processing and structured output for bigger jobs, things like multi-server health checks or scheduled report generation, where the log file becomes the audit trail rather than an afterthought. The official GNU Bash reference manual is worth bookmarking once you start combining traps, process substitution, and file descriptors like this.

Now that you have a working pattern for both pieces, timestamped logging with severity levels and structure-aware XML parsing, you can stop guessing why a script failed and start reading the answer straight out of a log file. The next logical step is learning how to write reusable bash functions so the logging setup here becomes a shared block you drop into every script instead of retyping it.

Related Articles

• Linux Logging Best Practices
• Bash Script Exit Codes and Error Handling (Part 5 of 34)
• Bash Functions: Writing Reusable Code (Part 21 / 34)
• Switch From Cron Jobs to Systemd Timers
• Linux Bash Scripting Automation