{"id":252,"date":"2026-10-13T03:11:09","date_gmt":"2026-10-13T03:11:09","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2010\/05\/03\/reading-xml-file-using-shell-script\/"},"modified":"2026-10-13T03:11:09","modified_gmt":"2026-10-13T03:11:09","slug":"reading-xml-file-using-shell-script","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/reading-xml-file-using-shell-script\/","title":{"rendered":"Reading XML in Shell Scripts: Safer Patterns with xmlstarlet and xmllint"},"content":{"rendered":"\n

Reading XML directly in shell scripts is common in lightweight automation, legacy jobs, and restricted runtime environments. This guide explains the classic shell-only pattern, where it breaks, and how to extract XML values more reliably with XPath-capable command-line tools.<\/p>\n\n\n\n

Originally published on 2010-05-03; fully revised and updated.<\/em><\/p>\n\n\n\n

\"Reading<\/p>\n\n\n\n

The XML shape this script pattern targets<\/h2>\n\n\n\n

The original post aimed to read specific fields (changelog, name, date, email) from XML using Bash only. A representative XML file for that use case looks like this:<\/p>\n\n\n

<entry<\/span>><\/span>\n  <changelog<\/span>><\/span>Fixed a new bug<\/changelog<\/span>><\/span>\n  <name<\/span>><\/span>Shoaib Mir<\/name<\/span>><\/span>\n  <date<\/span>><\/span>Sun, 02 May 2010<\/date<\/span>><\/span>\n  <email<\/span>><\/span>shoaibmir[@]gmail.com<\/email<\/span>><\/span>\n<\/entry<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
What the original grep\/sed approach does<\/h2>\n\n\n\n
The original technique loops over tag names, uses grep<\/code>\/sed<\/code> to strip tags, then assigns values to variables. A simplified equivalent is:<\/p>\n\n\n
#!\/usr\/bin\/env bash<\/span>\n\nfor<\/span> key in changelog name date email; do<\/span>\n  output=\"$(grep \"<\/span>$key\" log.xml | tr -d '\\t' | sed -e \"<\/span>s#<${key}>##\" -e \"s#<\/${key}>##\")\"<\/span>\n  eval<\/span> \"${key}=\\\"${output}\\\"\"<\/span>\ndone\n\necho<\/span> \"$changelog\"<\/span>\necho<\/span> \"$name\"<\/span>\necho<\/span> \"$date\"<\/span>\necho<\/span> \"$email\"<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
This can work for tightly controlled, single-line XML, but it is fragile<\/strong> for nested elements, attributes, namespaces, multiline text, or repeated nodes. Using eval<\/code> also increases risk if input is not trusted.<\/p>\n\n\n\n
Use XPath tools for safer shell scripts<\/h2>\n\n\n\n
Option 1: xmlstarlet (shell-friendly XPath queries)<\/h3>\n\n\n\n
If xmlstarlet<\/code> is available, it is usually the cleanest CLI option for extracting XML fields in Bash.<\/p>\n\n\n
#!\/usr\/bin\/env bash<\/span>\nset -euo pipefail\n\nfile=\"${1:-log.xml}\"<\/span>\nkeys=(changelog name date email)\n\nif<\/span> ! command -v xmlstarlet >\/dev\/null<\/span> 2<\/span>>&1<\/span>; then\n  echo<\/span> \"xmlstarlet is required but not installed\"<\/span> >&2<\/span>\n  exit<\/span> 1<\/span>\nfi\n\nfor<\/span> key in \"${keys[@]}\"<\/span>; do<\/span>\n  value=\"$(xmlstarlet sel -t -v \"<\/span>\/entry\/${key}\" -n \"<\/span>$file\")\"<\/span>\n  printf '%s: %s\\n'<\/span> \"$key\"<\/span> \"$value\"<\/span>\ndone<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Option 2: xmllint with XPath<\/h3>\n\n\n\n
xmllint<\/code> can also extract scalar values with XPath and is commonly present where libxml2 tooling exists.<\/p>\n\n\n
#!\/usr\/bin\/env bash<\/span>\nset -euo pipefail\n\nfile=\"${1:-log.xml}\"<\/span>\n\nfor<\/span> key in changelog name date email; do<\/span>\n  value=\"$(xmllint --xpath \"<\/span>string(\/entry\/${key})\" \"<\/span>$file\" 2>\/dev\/null)\"<\/span>\n  printf '%s: %s\\n'<\/span> \"$key\"<\/span> \"$value\"<\/span>\ndone<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Approach comparison<\/h2>\n\n\n\n
Method<\/th>Strengths<\/th>Limitations<\/th>Best fit<\/th><\/tr><\/thead>
grep + sed (+ eval)<\/td>No extra XML tool required; fast for trivial input<\/td>Brittle parsing; unsafe patterns with untrusted input; fails on many valid XML structures<\/td>Short-lived scripts with strictly controlled XML format<\/td><\/tr>
xmlstarlet sel<\/td>Real XML parsing with XPath; script-friendly output<\/td>Requires xmlstarlet availability<\/td>Reliable extraction in CI\/CD scripts and automation jobs<\/td><\/tr>
xmllint –xpath<\/td>Real XML parsing; XPath support; often available in Unix-like environments<\/td>XPath output\/error handling can need extra care<\/td>Environments where xmllint is already installed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Decision flow for shell-based XML extraction<\/h2>\n\n\n\n
\nflowchart TD\n    A[Need XML values in a shell script] --> B{XML input is strictly controlled}\n    B -- yes --> C{Only simple flat tags}\n    C -- yes --> D[Temporary grep sed approach]\n    C -- no --> E[Use XPath parser]\n    B -- no --> E[Use XPath parser]\n    E --> F{xmlstarlet available}\n    F -- yes --> G[Use xmlstarlet sel]\n    F -- no --> H{xmllint available}\n    H -- yes --> I[Use xmllint xpath]\n    H -- no --> J[Add XML tool dependency]\n    D --> K[Document limits and migration plan]\n    G --> L[Add validation and error handling]\n    I --> L\n    J --> L\n<\/pre>\n\n\n\n
Best practices<\/h2>\n\n\n\n