Cross-Platform Handling

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A user asks to open a local HTML report on Windows, Linux desktop or a headless host. The teaching file exists, but an OS label does not establish graphical/opening capability.

Mechanism

Verify platform, absolute path and effective opener, then use a supported adapter. Use project-known Windows association/PowerShell behavior, xdg-open only with an available Linux desktop, or deliver an absolute path on unsupported/headless hosts. Pass filenames as data, not shell code.

Bad example

Run xdg-open everywhere, claim opened after failure and concatenate space-containing paths into commands.

Good example

Verify the teaching report and allowed absolute path, OS and graphical/association capability. Use verified native mechanisms with structured arguments. Linux requires xdg-open plus a desktop; Windows follows supported project handling. Headless returns the path with no automatic-open claim. Preserve actual failures rather than OS/exit assumptions.

Why the change matters

Adapters connect the user’s goal to effective capability; explicit fallback retains file access without pretending a command implies a display session.

Observable expectation

Teaching cases are supported desktop→adapter/result, headless→path and missing command→fallback. Paths with spaces stay one argument.

Reject false-open claims or nonexistent files called usable. No real application starts.

Limits

Readable reports are not necessarily correct, and launching does not prove user visibility. Device capabilities/permissions vary; provenance is unconfirmed and branches authorize no installation/access expansion.