---
id: "bug-1596"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "scheduler"
severity: "unknown"
timestamp: "2026-08-19T08:00:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/scheduler/src/repl.c (repl_split_tokens)"]
tags: ["scheduler", "repl", "jobid", "quoting", "parsing", "ux"]
related: ["bug-1591"]
legacy: true
---

# bug-1596: User-reported: `info job "0-15-1787129769-0[0]"` (jobid copied from `info jobs`' own output…

## Description
User-reported: `info job "0-15-1787129769-0[0]"` (jobid copied from `info jobs`' own output, wrapped in double quotes out of habit) returns "[sim] info job: no such job 0 (0-0-0-0)" even though the job is genuinely present -- the identical jobid without quotes works.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
repl_info_job() already correctly calls parse_jobid() (lib/utils.c) with a strtoull() fallback -- confirmed NOT the bug. parse_jobid()'s two regexes (REGEX_JOBARRAY_ID/REGEX_JOBID, src/include/config.h) both require a whole-string anchor match (pmatch[0].rm_so==0 && pmatch[0].rm_eo==len). repl_split_tokens() (repl.c) is a plain whitespace tokenizer with no quote-awareness, so a quoted argument's token literally includes the surrounding `"` characters. Those quote characters break the anchor match (the regex still matches the interior substring, but not starting at offset 0 / ending at len), parse_jobid() returns -EINVAL, and the strtoull() fallback then parses a string beginning with `"` -- not a valid numeric prefix -- returning 0. MAKE_JOBID(0,0,0,0,0) formats back as "0-0-0-0", exactly matching the reported output.

## Fix
Fixed as part of task 12.5. repl_split_tokens() (repl.c) now strips one matching pair of leading/trailing `"` or `'` characters from each extracted token (length >= 2, first == last == a quote char) before returning it -- applies uniformly to every REPL command argument (info job/queue/worker/resource names, break filters), not special-cased to `info job`. New test in test_repl_breakpoints_inspection.c asserts `info job "<jobid>"` (double-quoted) and `info job '<jobid>'` (single-quoted) both resolve the same job as the unquoted form.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1591