Will It Vibe?Iterating over 'ls' output in a for loop
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
for f in $(ls ...) (or the backtick equivalent) splits ls's output on whitespace, so filenames containing spaces, tabs, or newlines get silently torn into multiple, wrong loop entries. Iterating the directory directly (for f in dir/*) or using find handles arbitrary filenames correctly.
Why it matters
for f in $(ls ...) splits ls's output on whitespace before the loop ever sees it, so any filename containing a space, tab, or newline is silently torn into multiple, wrong loop entries instead of being treated as one file. It also breaks on filenames that happen to look like shell glob patterns.
How to fix it
Iterate the directory directly instead of parsing ls's text output: for f in dir/*; do ... done handles arbitrary filenames correctly because the shell does the globbing itself rather than splitting text. For anything recursive or filtered, use find dir -type f -print0 | while IFS= read -r -d '' f; do ... done.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo