@oazmi/kitchensink - v0.10.1
    Preparing search index...

    Interface SpawnCommandConfig

    configuration options for the spawnCommand function.

    interface SpawnCommandConfig {
        args: string[];
        cwd?: string | URL;
        env?: Record<string, string | undefined>;
        signal?: AbortSignal;
        detached?: boolean;
    }

    Hierarchy (View Summary)

    Index

    Properties

    args: string[]

    cli-arguments to pass to the process.

    [] (empty array)

    cwd?: string | URL

    set the working directory of the process.

    if not specified, the cwd of the parent process is inherited.

    undefined

    env?: Record<string, string | undefined>

    set the environment variables of the process.

    I don't know whether these get appended, or completely clear out the existing environment variables, so that the new process only gets a new slate of environment variables that are specified here.

    undefined (i.e. inherit environment variables from the current js-runtime)

    signal?: AbortSignal

    provide an optional abort signal to force close the process, by sending a "SIGTERM" os-signal to it.

    undefined

    detached?: boolean

    specify if the newly spawned process should be a child of the current js-runtime process.

    in theory, this would allow the spawned process to exist after the current process has exited. however, since we listen to the stdout and stderrs (i.e. pipe them), the current js-runtime will not exit, unless you provide an abort signal and trigger it once you're done with your js shenanigans.

    moreove, this option is not available for the txiki.js runtime.

    TODO: actually, I'm feeling too lazy to implement the logic for allowing the js-runtime to abort when signal is triggered, while allowing the spawned process to outlive (i.e. we shouldn't be closing it ourselves when the abort signal is fired).