Skip to content

main: don't parse the -r repeat count again as a -c option - #375

Merged
jiegec merged 1 commit into
lsof-org:masterfrom
Ar-maan05:repeat-count-suffix
Nov 2, 2026
Merged

jiegec merged 1 commit into
lsof-org:masterfrom
Ar-maan05:repeat-count-suffix

Conversation

@Ar-maan05

Copy link
Copy Markdown
Contributor

-r with a count also turns the count into a -c command filter, so you get the right number of repeats but nothing in them:

$ lsof -r1c2 -a -p $$ -Fp
before: =======  ======= (no listings)
after:  two listings of the process

after c<N> is read there's nothing left in the argument, but the code only checks for the m mark, so it rewinds and c2 gets parsed again as -c 2. without -a the bug is easier to miss since -p still selects the process.

the fix stops when the argument is used up. case-20-repeat-count.bash only counted the ======= lines wich is why it passed, so i extended it to check the process is listed. it fails before and passes after, and make check is clean on linux.

after reading c<N> from "-r1c2" nothing is left in the argument, but the code only checks for the m<fmt> mark, so it rewinds to just after the time and "c2" gets parsed as "-c 2". that selects commands starting with "2" insted of limiting the repeats. stop when the argument is used up.

the repeat test only counted the ======= markers, wich still come out right, so also check that the process gets listed.
@jiegec
jiegec merged commit 0eaea32 into lsof-org:master Nov 2, 2026
17 checks passed
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.

2 participants