Skip to content

Explicitly document in openrc-run(8) man page that service scripts must be POSIX sh #1067

Description

@flexibeast

Currently, the openrc-run(8) man page doesn't explicitly state what shell flavour is acceptable in service scripts. The closest it comes is referencing sh(1p) in SEE ALSO.

Given that there are many common shell constructs which aren't actually POSIX - cf. the "Shell/Scripting" page on the Gentoo wiki - i feel it's important to note that scripts currently must be POSIX sh (although #288, opened in 2019 and last updated with the "enhancement" label at the start of 2023, discusses adding support for them to be in Bash). In the absence of this information, people might end up mystified when they write service scripts that 'should' work but somehow don't.

To give a concrete example of people assuming service scripts can be written in Bash, a contributor has just added a script for a Docker user service to the wiki, and in doing so, has specified that its lang is bash. (And, side note, i'll be suggesting to that person that they contribute that script to the Docker ebuild.)

EDIT: i've just noticed that service-script-guide.md says:

Service scripts are shell scripts. OpenRC aims at using only the standardized POSIX sh subset for portability reasons. The default interpreter (build-time toggle) is /bin/sh, so using for example mksh is not a problem.

That seems to me to imply that #288 has actually been implemented? But regardless, this suggests to me that the openrc-run(8) man page should be built based on what interpreter has been chosen for the build, so that e.g. users on Gentoo, where the default interpreter is used, will get a man page for openrc-run(8) that starts with something like:

openrc-run is basically an interpreter for shell scripts which provides an easy interface to the often complex system commands and daemons. On this system, OpenRC has been built with /bin/sh (POSIX shell) as the interpreter for service scripts.

When a service runs a command it first ...

where "POSIX sh" is explicitly mentioned, rather than just "/bin/sh", because otherwise it doesn't necessarily convey what constructs can and can't be used to anyone who isn't regularly writing shell.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions