run-llama/liteparse · error · Error

no data on stdin (input `-` expects a document piped in…

Error message

no data on stdin (input `-` expects a document piped in, e.g. `curl … | liteparse parse -`)

What it means

LiteParse throws this when the CLI input is `-` (stdin) but nothing was piped in. The CLI reads all of process.stdin and, if zero bytes arrive, it cannot distinguish 'closed with no data' from 'forgot to pipe', so it fails with guidance showing the expected pipe usage. It exists to fail fast with an actionable message instead of parsing an empty document.

Solutions

Pipe an actual document into the command: `curl -s https://example.com/doc.pdf | liteparse parse -`.
If you meant a file on disk, pass the path instead of `-`: `liteparse parse ./doc.pdf`.
Check that the upstream command in the pipeline actually succeeded and emitted bytes (`set -o pipefail` in bash helps surface upstream failures).

Example fix

// before
liteparse parse -
// after
curl -s https://example.com/doc.pdf | liteparse parse -

Defensive patterns

Strategy: validation

Validate before calling

const isTTY = process.stdin.isTTY;
if (process.argv.includes('-') && isTTY) {
  console.error('input `-` requires piped stdin, e.g. curl ... | liteparse parse -');
  process.exit(2);
}

Try / catch

try {
  await cli.parseAsync();
} catch (e) {
  if (e.message.includes('no data on stdin')) {
    console.error('Nothing was piped in. Usage: curl -s <url> | liteparse parse -');
    process.exit(2);
  }
  throw e;
}

Prevention

Never run the CLI interactively with `-`; always pipe a real document.
Use `set -o pipefail` in bash scripts so an empty upstream pipe fails the job visibly.
Prefer explicit file paths over `-` unless streaming is required.

When it happens

Trigger: Running `liteparse parse -` or `liteparse stats -` without piping any bytes into stdin, e.g. running it interactively in a terminal and pressing Ctrl+D immediately, or a shell script where the upstream command in the pipe produced no output.

Common situations: CI jobs where the curl/wget step failed silently upstream; forgetting the `|` and running `liteparse parse -` directly; piping from a file that is empty; copy-pasting a documented example without the `curl ... |` prefix.

Understand the failure class

Background: "must not be empty", "cannot be empty" — required-field validation errors across open-source libraries — this error's family across 41 libraries.

Related errors

AI-assisted analysis of run-llama/liteparse@22d2dd8cd7 (2026-09-08). Data as JSON: /api/errors/aad44eb371609ce6. Report an issue: GitHub.

Appendix: source

Thrown at packages/node/src/cli.ts:28

  .name("liteparse")
  .description("Fast, lightweight PDF and document parsing")
  .version("2.0.0");

/**
 * Resolve a CLI `<file>` argument into a parser input. `-` means read the
 * document from stdin (e.g. `curl -sL … | liteparse parse -`); anything else is
 * passed through as a path. Streaming stdin (rather than `readFileSync(0)`)
 * avoids EAGAIN on non-blocking pipes.
 */
async function resolveInput(file: string): Promise<string | Buffer> {
  if (file !== "-") return file;
  const chunks: Buffer[] = [];
  for await (const chunk of process.stdin) {
    chunks.push(chunk as Buffer);
  }
  const bytes = Buffer.concat(chunks);
  if (bytes.length === 0) {
    throw new Error(
      "no data on stdin (input `-` expects a document piped in, e.g. `curl … | liteparse parse -`)",
    );
  }
  return bytes;
}

/** Collect repeated `--ocr-server-header "Name: Value"` flags into an object. */
function collectHeader(
  value: string,
  previous: Record<string, string> = {},
): Record<string, string> {
  const idx = value.indexOf(":");
  if (idx === -1) {
    throw new Error(`invalid header '${value}', expected 'Name: Value'`);
  }
  const name = value.slice(0, idx).trim();
  if (name === "") {
    throw new Error(`invalid header '${value}', empty header name`);

View on GitHub (pinned to 22d2dd8cd7)