Fix atrocity arg parsing

[supervoidcoder]

No description provided.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-atrocity-arg-parsing

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[supervoidcoder]

@coderabbitai hmm I have so much planned for this... What do you think of much smarter arg parsing I think this will be pretty fun

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Get the diff for this PR to see what's being changed
gh pr diff 91

# Also check the current state of main.cpp to understand the context
echo "=== Current main.cpp content ==="
cat main.cpp | head -500

Length of output: 22018

---

@supervoidcoder Oh this is exciting! I love where you're going with this. 🎉

The current changes moving to std::vector<std::string> are already a solid foundation - it's way safer than raw pointer arithmetic and makes the code less error-prone. But yeah, there's SO much room to make this even smarter!

Here are some ideas for taking this to the next level:

1. Structured Argument Parser Class
You could create a dedicated class that handles all the parsing logic:

• Store flags and their values in a map/unordered_map
• Support both short (-p) and long (--pid) format
• Handle flag aliases automatically
• Make it easy to check if (args.has("pid")) instead of manual string comparisons

2. Subcommands Support
Since you have process inspection, you could potentially add subcommands like:

• win-witr inspect <name/pid>
• win-witr list (show all processes)
• win-witr monitor <name/pid> (continuous monitoring)

3. Value Validation at Parse Time
Instead of parsing --pid and then converting/validating later, validate during the parse phase:

• Type-safe getters like args.getInt("pid") that throw meaningful errors
• Enum-based flags for compile-time safety
• Required vs optional argument tracking

4. Better Error Messages
With smarter parsing you can provide helpful suggestions:

• "Did you mean --pid instead of --pd?"
• "Flag --pid requires a value"
• Auto-generate usage info from the parser configuration

5. Chained Operations

win-witr --pid 1234 --details --ports --cmdline

Where each flag adds a section to the output.

The comment about "never increment the actual variable" suggests you've hit some of the pain points of manual parsing - a proper parser would handle that state management for you automatically!

What direction were you thinking? I'm curious what you have planned! 🚀

---

🧠 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: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.

[supervoidcoder]

@coderabbitai i'm thinking of adding a --verbose flag, but what would the shorthand be? -v is already for --version

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check current flag usage in main.cpp to see what's already taken
echo "=== Current flag usage in main.cpp ==="
rg -n "argv\[i\] == \"--?[a-z]" main.cpp || rg -n "\"--?[a-z]" main.cpp | head -50

Length of output: 221

---

@supervoidcoder Good question! This is a classic CLI flag collision. Here are your best options:

1. -V (capital V)

• Most common solution when lowercase is taken
• Used by: gcc -V, pip -V (shows version with capital)
• Intuitive since it's visually related to verbose
• Example: win-witr -V --pid 1234

2. No shorthand at all

• Just use --verbose
• Keeps things clean and unambiguous
• Used by many modern tools when conflicts arise
• You already do this with --pid

3. -d (for debug/detailed)

• Common alternative meaning
• Used by: ssh -d, curl -d (though curl's is for data)
• Fits well since verbose output is typically for debugging
• Example: win-witr -d --pid 1234

4. -vb or -vbs

• Unique and no collision
• A bit unconventional but memorable
• Less common in the wild

My recommendation: Go with -V (capital V). It's the most conventional solution in the Unix/Linux world when lowercase -v is already taken for version. Users will recognize the pattern immediately, and it keeps the mnemonic connection to "verbose."

Plus, if you ever want verbose levels later, you could do -VV or -VVV for increasing verbosity! 🚀

What do you think?

---

🧠 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: 0
File: :0-0
Timestamp: 2026-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

---

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.

[supervoidcoder]

@coderabbitai also i just remembered
since this is a windows only tool anyways, we should add windows style flags too
yknow, with the /

like shutdown /h instead of shutdown -h (which works too but yknow)

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder Oh YES! That's such a nice touch for a Windows-native tool! 🎯

You're absolutely right - Windows has its own CLI heritage with the / style flags, and it would make win-witr feel more at home on Windows. Plus, many Windows power users instinctively reach for / first.

The best part: You can support both styles simultaneously! Many modern Windows tools do this:

• shutdown /h ✅
• shutdown -h ✅ (also works)
• ipconfig /all vs ipconfig -all (both work in many tools)

Implementation approach:

When parsing args, just normalize the prefix:

std::string normalizeFlag(const std::string& arg) {
    // Convert /flag to --flag or /-f to -f
    if (arg[0] == '/') {
        if (arg.length() == 2) {
            return "-" + arg.substr(1);  // /v -> -v
        } else {
            return "--" + arg.substr(1); // /verbose -> --verbose
        }
    }
    return arg;
}

Then parse as usual. This way you get:

• win-witr /pid 1234 ✅
• win-witr --pid 1234 ✅
• win-witr /v (for version) ✅
• win-witr /V (for verbose) ✅
• win-witr /verbose ✅

Examples of how it would look:

win-witr /p 1234
win-witr /pid 1234 /V
win-witr /name explorer.exe /verbose

Gives it that authentic Windows CLI vibe! And users coming from Unix/Linux backgrounds will still feel at home with - and --. Win-win! 🚀

Do you want to support both styles, or go full Windows and use / exclusively?

---

✏️ Learnings added

Learnt from: supervoidcoder
URL: https://github.com/supervoidcoder/win-witr/pull/91

Timestamp: 2026-02-16T15:24:08.444Z
Learning: The user wants to add Windows-style flag syntax using `/` prefix (e.g., `/pid`, `/v`, `/verbose`) to win-witr since it's a Windows-only tool, following Windows CLI conventions like `shutdown /h`. Supporting both Unix-style (`-`, `--`) and Windows-style (`/`) flags simultaneously is preferred for user flexibility.

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-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

---

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.

---

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.