process

Generated by tinox doc

tinox.core.process, bundled with the compiler and also available as a standalone tinox-central package.

Pid args env

import tinox.core.process
class Main
{
    fnc main() -> Int32
    {
        println("pid = " + Process::pid().toString())
        const args: List<String> = Process::args()
        println("arg count = " + args.len().toString())
        Process::setEnv("MY_VAR", "hello")
        println("MY_VAR = " + Process::env("MY_VAR"))
        Process::sleep(1)
        return 0
    }
}

fn processSignal(handle: Int64, sig: Int64) → Int64

fn processWaitReadable(handle: Int64, timeoutMs: Int64) → Int64

class InteractiveProcess

* A long-lived, incrementally-driven subprocess -- unlike * Process::run() (blocks until exit, returns the full captured * output), this spawns and returns immediately; the caller drives it * for the duration of an interactive session (e.g. `kubectl exec -i` * bridged to a terminal) via writeStdin/readOutput. start() uses a PTY * with merged stdout/stderr; startPiped() uses separate pipes for tools * speaking line protocols such as JSON over stdio.

Fields

handle Int64

Methods

fn start(argv: List<String>) → InteractiveProcess

argv[0] is the program (resolved via PATH like execvp), argv[1..] its arguments -- same argv-based, no-shell contract as Process::run(). Named start(), not spawn(): `spawn` is a reserved keyword (the language's own thread-spawn construct).

fn startPiped(argv: List<String>, cwd: String, env: List<String>) → InteractiveProcess

* Starts a child with pipes: stdin is not a TTY, input is not echoed, * and stderr is separate. cwd/env follow Process::runWithOptions. * Call kill() to release resources, including after normal exit. * Serialize reads and lifecycle operations on each handle. Writes * block; use a concurrent reader when sending large input payloads.

fn closeStdin(proc: InteractiveProcess) → Nothing

Closes pipe stdin to deliver EOF. Idempotent; no effect on PTYs.

fn readLine(proc: InteractiveProcess, timeoutMs: Int64) → String

* Reads a stdout line, including its newline, or the final unterminated * line at EOF. Returns "" on timeout/EOF. Partial lines are retained * across timeouts. timeoutMs < 0 waits indefinitely; 0 polls. * Pipe mode only. Reads also buffer stderr to avoid pipe deadlocks; * drain both streams regularly to bound memory use.

fn readStderr(proc: InteractiveProcess, timeoutMs: Int64) → String

Reads available pipe stderr; timeout/EOF returns "".

fn exitCode(proc: InteractiveProcess) → Int64

Exit status, -signal if killed, or -9223372036854775808 while running.

fn writeStdin(proc: InteractiveProcess, data: String) → Nothing

Writes to the process's stdin. Best-effort: silently stops writing if the process has already exited -- check isAlive() to detect that.

fn readOutput(proc: InteractiveProcess, timeoutMs: Int64) → String

* Reads available output (possibly a partial line). Pipe mode reads * stdout only and also buffers stderr. Output remains readable after * child exit. Returns "" on timeout/EOF; timeoutMs < 0 waits * indefinitely and 0 polls.

fn isAlive(proc: InteractiveProcess) → Bool

fn waitReadable(proc: InteractiveProcess, timeoutMs: Int64) → Int64

* Waits up to timeoutMs (< 0 forever, 0 polls) until a pipe-mode child * has output on stdout and/or stderr, or both streams ended, and * returns a bit mask: 1 = stdout data is ready, 2 = stderr data is * ready, 4 = both streams are at EOF and drained, 0 = timeout. The * data is buffered, so the following readOutput/readLine/readStderr * call with timeout 0 returns it immediately. This lets ONE reader * task follow stdout and stderr together without polling either.

fn signal(proc: InteractiveProcess, sig: Int64) → Bool

* Sends signal number sig (e.g. 2 = SIGINT, 15 = SIGTERM) to a running * child. A pipe-mode child leads its own process group and the signal * goes to the whole group, so tools it started receive it too. Returns * false when there was nothing to signal (the child already exited).

fn terminate(proc: InteractiveProcess) → Bool

Asks the process (and, in pipe mode, its process group) to stop with SIGTERM; follow up with kill() if it does not exit.

fn kill(proc: InteractiveProcess) → Nothing

Kills the process (if still running; in pipe mode its whole process group) and closes its pipes. Safe to call even if it already exited.

class Process

Methods

fn exit(code: Int64) → Nothing

fn sleep(ms: Int64) → Nothing

fn pid() → Int64

fn args() → List<String>

fn env(name: String) → String

fn setEnv(name: String, value: String) → Nothing

fn run(argv: List<String>, timeoutMs: Int64, stdin: String) → ProcessResult

* Runs an external program via argv (never a shell): argv[0] is the * program (resolved via PATH like execvp), argv[1..] are its * arguments, each passed as a distinct native argument. Safe to use * with untrusted argument values (e.g. taken from an HTTP path * param) -- there is no shell in between to interpret them. * * timeoutMs <= 0 means no timeout. On timeout the process is killed * and ProcessResult.timedOut is true. `stdin` is fed to the child's * standard input (empty string = closed/empty stdin, the common * case for a program that only reads argv, e.g. `kubectl get`); * written concurrently with draining stdout/stderr, so a large * stdin payload can't deadlock against a chatty child (see * runtime.c's processRun comment for why that matters, e.g. * `kubectl apply -f -` with a sizeable manifest). * * @param argv the program and its arguments, e.g. ["kubectl", "get", "pods", "-n", namespace, "-o", "json"] * @param timeoutMs wall-clock timeout in milliseconds, or <= 0 for no timeout * @param stdin data to write to the child's stdin, or "" for none * @return the captured stdout/stderr/exit code

fn runWithOptions(argv: List<String>, timeoutMs: Int64, stdin: String, cwd: String, env: List<String>) → ProcessResult

* Like run(), with child-only working directory and environment. * cwd="" inherits the current directory. env entries KEY=value set * or override inherited variables; bare KEY removes a variable. * An empty list inherits the environment unchanged. PATH lookup uses * the parent's PATH (posix_spawnp); use an explicit executable path * when overriding PATH. Invalid cwd/exec failures return code 127.

class ProcessResult

* Result of Process::run(): captured stdout/stderr, the exit code, and * whether the process was killed for exceeding its timeout. * * exitCode is -1 when timedOut is true (no real exit status exists in * that case), or -signal when the process was terminated by a signal * (matches the negative-on-signal convention used elsewhere in the * runtime). A conventional 127 means "exec failed" (e.g. the program * wasn't found on PATH) -- the same convention a shell uses.

Fields

`stdout`	`String`
`stderr`	`String`
`exitCode`	`Int64`
`timedOut`	`Bool`

Methods

fn new(stdout: String, stderr: String, exitCode: Int64, timedOut: Bool) → ProcessResult

fn success() → Bool

True if the process ran to completion with exit code 0.