Portability

tori’s role is to manage configuration files and installed packages, allowing the transfer of this configuration between different versions of an operating system or even between different Unix and Unix-like operating systems, provided they are supported.

Given this purpose, it ideally should not require the user to install even a single package in order to run. It must be a portable application with minimal dependencies so it can perform its functions on brand new systems where very few packages have been installed and little to no configuration has been done.

To achieve this portability and independence, it is meant to run on a POSIX-compatible shell where POSIX utilities are available. If a system does not provide this, it is very unlikely tori can function.

Note that while tori expects a POSIX shell, it is not meant as a universal tool able to run on any POSIX-compliant system. A POSIX shell is required because it is the interpreter for tori’s source code and it was chosen because it comes pre-installed on most Unix-like systems.

For some of its functionalities, tori needs to be running in a supported operating system. It has specific package management and service management features that work by abstracting the actual operating system’s interfaces behind a function that detects what system is running and then runs the appropriate commands.

The currently supported operating systems are tracked in the Support Matrix page.

While it strives to do so, in some situations, tori may perform tasks by relying on resources or features not specified by POSIX, such as when there is no option or the available option presents readability or usability issues.

In these situations, tori tends to rely on specific functions that will switch their behavior depending on the operating system’s support for the operation. Regardless, all of its features are expected to work under supported operating systems.

Below is a list of assumptions made about what is supported in the running environment:

• shell
  • local
  • read with read -r -p <prompt> <variable_with_user_input> syntax
  • mkdir with -p
  • find
  • grep
  • sed
  • xargs
  • uname
  • date
    • with nanoseconds as %N
      • While nanoseconds in date is not specified by POSIX, it is available on the currently supported systems and is used only when $DEBUG is set in the environment
    • with -r for getting a modification date
      • This feature is not specified by POSIX. So far it was tested on FreeBSD and Void Linux
  • env at /usr/bin/env
    • While this may be an issue from a portability standpoint, hardcoding the path where sh is also poses another portability issue. A more robust way to find it would be desirable

The POSIX specification used as reference is the IEEE Std 1003.1-2024 Edition.

tori is developed and tested on the sh Almquist shell as shipped by FreeBSD and the dash Almquist shell as shipped by Void Linux.