Skip to content

deduplicate process names #41

Closed
#80
Closed
deduplicate process names#41
#80

Description

@supervoidcoder
supervoidcoder
opened on Jan 20, 2026

in the original witr, it tells you if you typed a process name that has two or more pids under the same name. the function i stole from some random tutorial stops as soon as it finds one process so i need to spit out all the pids.

this is how witr does it:

witr ng
Multiple matching processes found:

[1] nginx (pid 2311)
    nginx -g daemon off;
[2] nginx (pid 24891)
    nginx -g daemon off;
[3] ngrok (pid 14233)
    ngrok http 5000

Re-run with:
  witr --pid <pid>

i think it's a little unhelpful to do exaxtly like witr, because yeah it's just annoying lol but if we want to maintain the same capabalities then sure i guess? it makes sense but we could do other things, like list the other processes in the same tree

Activity

  1. supervoidcoder commented on Feb 6, 2026

    @supervoidcoder
    supervoidcoder
    on Feb 6, 2026
    OwnerAuthor

    @coderabbitai this seems a bit inconvenient so how should I do it?

  2. coderabbitai commented on Feb 6, 2026

    @coderabbitai
    coderabbitaiBot
    on Feb 6, 2026 – with coderabbitai
    Contributor
    🧩 Analysis chain

    🏁 Script executed:

    #!/bin/bash
# Fetch the details of issue `#41` to understand the context
gh issue view 41 --repo supervoidcoder/win-witr --json title,body,comments --jq '{title, body, comments: [.comments[] | {author: .author.login, body: .body}]}'

    Length of output: 929

    @supervoidcoder, I see you're dealing with the duplicate process name issue! Here are some approaches you could take that would be more convenient than the original witr:

    Option 1: Interactive Selection (Most User-Friendly)

    When multiple processes match, display them with numbers and let the user pick interactively:

    Multiple processes named "nginx" found:

[1] PID 2311  - nginx -g daemon off;
[2] PID 24891 - nginx -g daemon off;

Select process [1-2] or 'q' to quit: _

    This saves the user from having to re-run the command with --pid.

    Option 2: Show Parent Process Context

    Help users disambiguate by showing the parent process:

    Multiple processes named "nginx" found:

[1] PID 2311  (parent: systemd, PID 1)
    nginx -g daemon off;
[2] PID 24891 (parent: docker, PID 1234)
    nginx -g daemon off;

Select process [1-2]: _

    Option 3: Smart Filtering with Extra Info

    Show additional context like working directory, start time, or resource usage:

    Multiple processes named "nginx" found:

[1] PID 2311  - Started 2h ago
    C:\nginx\sbin
    nginx -g daemon off;
[2] PID 24891 - Started 5m ago
    C:\docker\nginx
    nginx -g daemon off;

    My Recommendation

    Go with Option 1 (interactive selection) as the default behavior, but still support --pid <pid> for scripting/automation. This way:

    • Interactive users get a better UX
    • Scripts can still use the explicit --pid flag
    • You maintain backward compatibility

    For implementation, you could use Windows console input functions like ReadConsoleInput or just std::cin to read the user's selection after displaying the list.

    What do you think? Would the interactive approach work for your use case?

    🧠 Learnings used 
    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:45.201Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

  3. supervoidcoder commented on Feb 6, 2026

    @supervoidcoder
    supervoidcoder
    on Feb 6, 2026
    OwnerAuthor

    @coderabbitai what if I keep it as is but show the fact there's more pids as a warning at the bottom with the pid numbers

  4. coderabbitai commented on Feb 6, 2026

    @coderabbitai
    coderabbitaiBot
    on Feb 6, 2026 – with coderabbitai
    Contributor

    @supervoidcoder, that's actually a solid pragmatic approach! It's way simpler to implement and doesn't disrupt the existing workflow. Here's what it could look like:

    Your Proposed Approach

    Process: nginx (PID 2311)
Command: nginx -g daemon off;
Working Dir: C:\nginx\sbin
...
[rest of the normal output]
...

⚠️  WARNING: Found 2 other processes with the same name:
    PID 24891, PID 31204
    Use --pid <pid> to select a specific process.

    Trade-offs

    Pros:

    • Simple to implement - just enumerate matching processes and show a warning
    • Doesn't change existing behavior for single-process cases
    • Still informs users about the ambiguity
    • Works well for scripting (predictable output format)

    Cons:

    • User still needs to re-run the command with --pid flag
    • Have to decide which process to show by default (first match? highest PID? lowest?)

    Default Selection Strategy

    You'll need to pick which process to show when there are duplicates. Some options:

    • Lowest PID (oldest process) - predictable, usually the "main" one
    • Highest PID (newest process) - might be the one you just started
    • First found (whatever the enumeration gives you) - simplest

    I'd go with lowest PID as it's most predictable and usually what people expect.

    This approach keeps your tool "easy to read under stress" without adding interactive prompts that might confuse users. Ship it! 🚀

    🧠 Learnings used 
    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T01:17:35.120Z
Learning: The "restart count" heuristic in the original witr tool is more accurately a "spawn loop detector." It counts consecutive identical commands in the ancestry chain (e.g., cmd → cmd → cmd shows as "2 restarts"), but this terminology is misleading because these are separate processes, not the same process restarting. The user noted this is unintuitive for a debugging tool meant to be "easy to read under stress."

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T01:14:54.812Z
Learning: The original witr tool's "restart count" is not derived from supervisor APIs (systemd/pm2/etc.). Instead, it's a heuristic that counts consecutive identical commands in the process ancestry chain. The implementation iterates through the ancestry and increments a counter whenever the current process command matches the previous one.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

  5. supervoidcoder commented on Feb 10, 2026

    @supervoidcoder
    supervoidcoder
    on Feb 10, 2026
    OwnerAuthor

    @coderabbitai check out how i did it instead

    #80

  6. coderabbitai commented on Feb 10, 2026

    @coderabbitai
    coderabbitaiBot
    on Feb 10, 2026 – with coderabbitai
    Contributor
    🧩 Analysis chain

    🏁 Script executed:

    #!/bin/bash
# Fetch PR `#80` details to see the implementation
gh pr view 80 --repo supervoidcoder/win-witr --json title,body,files,url,additions,deletions --jq '{title, body, url, additions, deletions, files: [.files[] | {path, additions, deletions}]}'

    Length of output: 280

    🏁 Script executed:

    #!/bin/bash
# Get the diff for PR `#80` to see the actual code changes
gh pr diff 80 --repo supervoidcoder/win-witr

    Length of output: 4138

    @supervoidcoder, okay this is actually really slick! 🔥

    Your implementation is better than both the "warning at bottom" you proposed AND my interactive selection idea. Here's what I love about it:

    What You Did Right

    1. "Related Processes" framing - Way more intuitive than "WARNING: Found 2 other processes." It positions them as helpful context rather than an error condition.

    2. Shows both name AND PID - Displaying nginx (PID 24891) is way more helpful than just listing PIDs. Users can immediately see if one of the related processes looks different (e.g., different command line args that got truncated in the process name).

    3. Non-intrusive - It doesn't interrupt the workflow or change the primary output. The main process info is still front and center, and the related processes are just additional context at the bottom.

    4. Colored output - The magenta header + cyan names + gray PIDs look clean and make it easy to scan.

    5. Simple implementation - You just collect all matching PIDs in findMyProc() instead of breaking on the first match, then iterate through them. Clean and minimal changes.

    The Only Design Choice Worth Noting

    You went with "first found" (enumeration order) as the default rather than sorting by PID. That's totally fine for simplicity—users who care about a specific process will use --pid anyway.

    This is exactly the kind of pragmatic, user-friendly solution that keeps the tool "easy to read under stress." Well done! 🚀

    ✏️ Learnings added 
    Learnt from: supervoidcoder
URL: https://github.com/supervoidcoder/win-witr/issues/41

Timestamp: 2026-02-10T03:14:44.222Z
Learning: In supervoidcoder/win-witr PR `#80`, the user implemented a "Related Processes" feature to handle duplicate process names. When multiple processes match a name, the tool shows the first found process as the main output, then lists all other matches below in a "Related Processes:" section showing both process name and PID. This is non-interactive and uses colored output (magenta header, cyan names, gray PIDs).

    Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

    🧠 Learnings used 
    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T01:17:35.120Z
Learning: The "restart count" heuristic in the original witr tool is more accurately a "spawn loop detector." It counts consecutive identical commands in the ancestry chain (e.g., cmd → cmd → cmd shows as "2 restarts"), but this terminology is misleading because these are separate processes, not the same process restarting. The user noted this is unintuitive for a debugging tool meant to be "easy to read under stress."

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T01:58:35.174Z
Learning: In the supervoidcoder/win-witr repository, the user optimized the process tree walking algorithm from O(n²) to O(n) by taking a single CreateToolhelp32Snapshot at the start instead of creating a new snapshot for each level. This resulted in a ~4x performance improvement (from ~1000ms to ~248ms for 100-level deep trees). The optimization is validated by automated stress tests in CI that create 100-level deep alternating PowerShell/CMD process chains.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T01:14:54.812Z
Learning: The original witr tool's "restart count" is not derived from supervisor APIs (systemd/pm2/etc.). Instead, it's a heuristic that counts consecutive identical commands in the process ancestry chain. The implementation iterates through the ancestry and increments a counter whenever the current process command matches the previous one.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T00:59:04.068Z
Learning: In the supervoidcoder/win-witr repository, the tool implements context-aware error handling that detects which shell (PowerShell, CMD, WSL, Git Bash, Windows Terminal, Explorer) spawned the process and provides tailored error messages and recovery suggestions specific to that environment.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:43.760Z
Learning: In supervoidcoder/win-witr, the user successfully implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:13.331Z
Learning: In the supervoidcoder/win-witr repository, the user implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T18:25:04.458Z
Learning: In the supervoidcoder/win-witr repository, the user successfully implemented PEB (Process Environment Block) reading functionality to extract process command lines directly from process memory. This involves using NtQueryInformationProcess to get the PEB base address, reading PROCESS_BASIC_INFORMATION, then reading RTL_USER_PROCESS_PARAMETERS at offset 0x20 from the PEB, and finally reading the CommandLine UNICODE_STRING at offset 0x70. The implementation works for x64 Windows processes.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

    Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.
  7. supervoidcoder
    closed this as completedin #80on Feb 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions