Collections, String, DateTime, OperatingSystem, Process, and XML Libraries: Core Concepts and Mental Model

1. The practical problem: useful automation crosses state boundaries

Earlier chapters focused on Robot Framework itself: syntax, suites, keywords, variables, and BuiltIn execution semantics. Real automation eventually touches data and the host system. A list may be transformed, a timestamp calculated, a file written, a process started, or XML parsed. The moment that happens, the suite owns more than Robot variables: it also owns operating-system resources and evidence.

The standard libraries make these boundaries explicit. That is preferable to hiding every action inside ad-hoc shell commands because the library name, keyword signature, returned value, and result log reveal what capability is being used.

2. Six libraries, six primary responsibilities

3. BuiltIn is automatic; these capabilities are opt-in

Robot Framework imports BuiltIn automatically. The libraries in this chapter are not automatically active. Importing them makes the dependency visible to readers and tooling.

*** Settings ***
Library    Collections
Library    String
Library    DateTime
Library    OperatingSystem
Library    Process
Library    XML

4. Inspect before changing anything

A safe workflow starts with read-only evidence. Confirm Robot/Python versions, inspect the intended workspace path, list existing files only inside the disposable lab root, and describe the child command before running it. For XML, parse a synthetic fixture before attempting mutation. For collections, log a copy or selected values rather than dumping confidential datasets.

robot --version
python --version
robot --dryrun suites/standard_libraries.robot

5. Returned value and mutated state are not the same thing

Some Collection keywords modify the object they receive. For example, Append To List mutates the list. Copy List returns a separate list and supports deepcopy=True when nested items also require independent ownership. By contrast, String transformation keywords normally return a new string/bytes value. XML modification keywords mutate a parsed element model, but a file on disk is unchanged until Save XML is called.

6. Process is a structured boundary, not a shell string

Process.Run Process accepts the executable and arguments as separate Robot cells. With the default shell=False, that avoids the quoting and injection hazards created when untrusted fragments are concatenated into a shell command. If shell=True is genuinely required, escaping becomes the caller’s responsibility and the risk boundary must be explicit.

The returned result object exposes rc, stdout, stderr, and redirected-output paths. These are better evidence than scraping one merged command string.

7. Process output can become a capacity problem

Process keeps stdout/stderr in memory by default. Robot Framework 7.3 increased the internal limit and eliminated an older deadlock failure mode at lower volumes, but large or unbounded output is still a bad design. Redirect large streams to files with stdout=.../stderr=..., merge with stderr=STDOUT only when that is the intended evidence model, or use DEVNULL when output is intentionally discarded.

8. Portability depends on path, encoding, and clock assumptions

OperatingSystem path arguments accept forward slashes portably and normalize them for Windows. A path embedded inside a shell string is different: Robot cannot safely normalize arbitrary shell syntax. Text files default to UTF-8 in modern OperatingSystem keywords, while process output defaults to console-oriented decoding unless output_encoding is configured. DateTime can operate in LOCAL or UTC; production evidence should state which clock convention it uses.

9. XML is structured data, not a string comparison problem

Parse XML accepts a path, XML text, or bytes and returns an ElementTree element. Querying tags, text, and attributes is more robust than comparing serialized XML strings because indentation, attribute ordering, and namespace representation can vary while the document meaning remains the same. XML parsing does not validate a schema automatically, and model mutations are not written back to the source file without Save XML.

10. Why this matters in DevOps

Standard libraries are the bridge between readable orchestration and host-level evidence. A CI job can transform a manifest, timestamp a result, launch a local verifier, inspect its return code, and produce a structured XML decision without obscuring which step touched which state store. That visibility is essential when a failed pipeline must be diagnosed later.

11. Knowledge check

12. Summary and next step

You now have the chapter’s ownership model: transform values in memory, use OperatingSystem only for owned filesystem/environment state, use Process for structured child execution, and treat XML as a parsed model. Lesson 2 turns that model into a complete local workflow with before/after evidence and cleanup.

Further reading

• Robot Framework 7.4.2 Collections — list/dictionary mutation, copying, comparison, and current type-conversion behavior.
• Robot Framework 7.4.2 String — text/bytes transformation and encoding-related keywords.
• Robot Framework 7.4.2 DateTime — timestamps, time intervals, conversion, LOCAL/UTC handling, and result formats.
• Robot Framework 7.4.2 OperatingSystem — portable file/directory/environment operations and deprecated process-running keywords.
• Robot Framework 7.4.2 Process — structured process invocation, result objects, output redirection, timeouts, and cleanup.
• Robot Framework 7.4.2 XML — parsing, XPath-style element lookup, verification, mutation, and explicit save semantics.
• Robot Framework 7.4.2 release — stable release baseline used in these lessons.