What causes "expected y/yes or n/no, got {:?}" in jdx/mise?

Answer with y, yes, n, or no at the prompt.

expected y/yes or n/no, got {:?}

Error message

expected y/yes or n/no, got {:?}

What it means

parse_confirm_answer accepts only prefixes of "yes"/"no" (including "y"/"n"); any other answer to an interactive confirmation prompt causes this error. It is reached via read_confirm_from_stdin when mise prompts the user (e.g. trust or install confirmations).

Source

Thrown at src/ui/prompt.rs:146

fn parse_confirm_answer(line: Option<&str>, default_yes: bool) -> eyre::Result<Confirmation> {
    let Some(line) = line else {
        // A decline, not `Unavailable`: the question *was* put on stderr and
        // stdin ended without an answer, so nothing was consented to.
        // `Unavailable` is reserved for the question never reaching anyone.
        // Keeping it a decline is also what every caller already assumed, and
        // leaves silence safe to read as "no" for any that come later.
        return Ok(Confirmation::No);
    };
    let answer = line.trim().to_lowercase();
    if answer.is_empty() {
        return Ok(default_answer(default_yes));
    }
    if "yes".starts_with(&answer) {
        Ok(Confirmation::Yes)
    } else if "no".starts_with(&answer) {
        Ok(Confirmation::No)
    } else {
        eyre::bail!("expected y/yes or n/no, got {:?}", line.trim())
    }
}

fn default_answer(default_yes: bool) -> Confirmation {
    if default_yes {
        Confirmation::Yes
    } else {
        Confirmation::No
    }
}

pub(crate) fn confirm_with_all<S: Into<String>>(message: S) -> eyre::Result<Confirmation> {
    let _lock = MUTEX.lock().unwrap(); // Prevent multiple prompts at once
    ctrlc::show_cursor_after_ctrl_c();

    if !can_prompt_dialog() {
        return Ok(Confirmation::Unavailable);
    }

View on GitHub (pinned to afd2eddd3a)

Solutions

Answer with y, yes, n, or no at the prompt.
When non-interactive, bypass the prompt with the appropriate flag (e.g. `mise trust --all`, `yes | ...` is fragile — prefer explicit flags).
If piping scripted input, ensure the line is exactly y/yes/n/no with no extra tokens on the same line.

Example fix

// before (script)
echo ok | mise trust
// after
mise trust --all

Defensive patterns

Strategy: fallback

Validate before calling

// For scripted answers, only feed exact accepted values:
const answer = 'y';
if (!['y', 'yes', 'n', 'no'].includes(answer.toLowerCase())) throw new Error(`bad prompt answer: ${answer}`);

Type guard

function isConfirmAnswer(v) { return ['y','yes','n','no'].includes(String(v).trim().toLowerCase()); }

Try / catch

try {
  run('mise trust');
} catch (e) {
  if (/expected y\/yes or n\/no/.test(String(e))) {
    run('mise trust --all'); // non-interactive path
  } else throw e;
}

Prevention

Use explicit non-interactive flags in scripts/CI instead of piping prompt answers.
Never pipe arbitrary text into mise commands that prompt.
Document accepted answers (y/yes/n/no) for any automation that wraps prompts.

When it happens

Trigger: Typing anything other than y/yes/n/no (case-insensitive prefixes) at a mise [Y/n] prompt, e.g. "ok", "1", an empty-but-nonmatching line, or piped input containing other text.

Common situations: Non-interactive shells piping unexpected text into mise (CI scripts, `echo foo | mise ...`), fat-fingering the prompt, or automation wrapping mise and feeding it unanticipated answers.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/ba9365b547d21f80. Report an issue: GitHub.