import type { ByteSource } from '../../../../io/types.ts'; import type { Session } from '../../../session/session.ts'; import type { DispatchFn } from '../../../../runtime/types.ts'; import type { BashArgs } from './types.ts'; import type { BuiltinCall, ExecuteStringFn, Result } from '../types.ts'; /** * Split a `bash`/`sh` argument list into flags, program and argv. * * Option parsing stops at the first operand, so everything after a script * file (or after `-c`'s program text) is positional, even when it looks * like a flag: `bash run.sh -c foo` passes `-c foo` to the script. `-` and * `--` both end it without being operands. * * `-c` takes the next *word*, never the rest of its cluster, which is where * bash's own parser departs from getopt: `bash -cx 'echo hi'` traces and * runs `echo hi` rather than running `x`. * * The two failure fields report what went wrong rather than a rendered * message, the way `ShellParse` does: the wording and the exit code belong * to the caller, which is the only thing that knows the head word the shell * was spelled as. */ export declare function parseBashArgs(args: string[]): BashArgs; /** * Run a nested shell: inline text from `-c`, or a script file. * * `name` is the head word (`bash` or `sh`). bash reports itself by * `argv[0]`, so the diagnostics follow the spelling the caller used. * * A nested shell is a child shell, so it runs on a snapshot of the session * and the caller gets its state back afterwards: `bash -c 'cd /x'` leaves the * caller where it was, as it does in bash, where the nested shell is a * separate process. `handleSource` is the opposite case and deliberately does * not snapshot, because a sourced file is the caller. */ export declare function handleBash(dispatch: DispatchFn, executeFn: ExecuteStringFn, args: string[], session: Session, stdin?: ByteSource | null, name?: string): Promise; /** The `bash` / `sh` arm; the head word names the nested shell. */ export declare function bashBuiltin(call: BuiltinCall): Promise; //# sourceMappingURL=bash.d.ts.map