Skip to content

xargs: don't emit an empty argument for a trailing blank - #829

Open
kevinburke wants to merge 1 commit into
uutils:mainfrom
kevinburke:xargs-trailing-blank
Open

xargs: don't emit an empty argument for a trailing blank#829
kevinburke wants to merge 1 commit into
uutils:mainfrom
kevinburke:xargs-trailing-blank

Conversation

@kevinburke

Copy link
Copy Markdown
Contributor

When input ended with a blank immediately before its final newline, xargs passed one extra empty argument to the command:

$ printf 'aaa \nbbb \n' | xargs printf '[%s]'
[aaa][bbb][]        # was
[aaa][bbb]          # GNU findutils 4.10.0, and now

WhitespaceDelimitedArgumentReader::next used one result.is_empty() check to answer two different questions. The whitespace branch broke out of the loop only if result was non-empty, so a delimiter seen before any token was skipped -- correct for blanks, but it left "we are mid-token" indistinguishable from "we have not started one". The EOF branch then used i == 0 as a proxy for "nothing was consumed", which is false for a final call that consumes only the trailing newline, so it flushed a zero-length token. Input ending without a newline happened to work because nothing was left to consume.

Track that state explicitly with an in_argument flag, mirroring seen_arg in GNU's read_line, and test result.is_empty() at EOF. A delimiter now ends an argument only when we are inside one, and EOF flushes only a non-empty buffer.

This also fixes a second symptom of the same conflation: quoted empty arguments were dropped mid-stream, since quotes start an argument without contributing any bytes. printf '"" x\n' gave [x] and now gives [][x], again matching GNU. An unterminated x '' at end of input still yields just [x], as GNU's if (p == linebuf) return -1 does.

-I/-i is unaffected: with a replace string and no explicit delimiter, xargs uses the newline-delimited reader instead.

When input ended with a blank immediately before its final newline,
xargs passed one extra empty argument to the command:

    $ printf 'aaa \nbbb \n' | xargs printf '[%s]'
    [aaa][bbb][]        # was
    [aaa][bbb]          # GNU findutils 4.10.0, and now

WhitespaceDelimitedArgumentReader::next used one `result.is_empty()`
check to answer two different questions. The whitespace branch broke out
of the loop only if `result` was non-empty, so a delimiter seen before
any token was skipped -- correct for blanks, but it left "we are
mid-token" indistinguishable from "we have not started one". The EOF
branch then used `i == 0` as a proxy for "nothing was consumed", which
is false for a final call that consumes only the trailing newline, so it
flushed a zero-length token. Input ending without a newline happened to
work because nothing was left to consume.

Track that state explicitly with an `in_argument` flag, mirroring
`seen_arg` in GNU's read_line, and test `result.is_empty()` at EOF. A
delimiter now ends an argument only when we are inside one, and EOF
flushes only a non-empty buffer.

This also fixes a second symptom of the same conflation: quoted empty
arguments were dropped mid-stream, since quotes start an argument
without contributing any bytes. `printf '"" x\n'` gave [x] and now gives
[][x], again matching GNU. An unterminated `x ''` at end of input still
yields just [x], as GNU's `if (p == linebuf) return -1` does.

-I/-i is unaffected: with a replace string and no explicit delimiter,
xargs uses the newline-delimited reader instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@codspeed-hq

codspeed-hq Bot commented Aug 11, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 20 untouched benchmarks


Comparing kevinburke:xargs-trailing-blank (bd7e3fe) with main (58c3af0)

Open in CodSpeed

@github-actions

Copy link
Copy Markdown

Commit bd7e3fe has test result changes:

GNU findutils testsuite:

Test results comparison:
  Current:   TOTAL: 495 / PASSED: 419 / FAILED: 75 / SKIPPED: 1
  Reference: TOTAL: 495 / PASSED: 417 / FAILED: 77 / SKIPPED: 1

Changes from main branch:
  TOTAL: +0
  PASSED: +2
  FAILED: -2

Test improvements (2):
  + r
  + sv-bug-18713

@codecov

codecov Bot commented Aug 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.99%. Comparing base (58c3af0) to head (bd7e3fe).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #829      +/-   ##
==========================================
+ Coverage   91.93%   91.99%   +0.05%     
==========================================
  Files          35       35              
  Lines        7253     7304      +51     
  Branches      378      378              
==========================================
+ Hits         6668     6719      +51     
  Misses        443      443              
  Partials      142      142              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant