[CLI] Improve user feedback when CCExtractor is run without an input file

[Drishtipixiee]

Description:
While testing CCExtractor from the terminal, I noticed that running the tool
without providing an input media file may be confusing for new users.

Steps to reproduce:

1. Build CCExtractor from source
2. Run: ./ccextractor
3. Observe the output / behavior

Expected behavior:
CCExtractor could display a clear message indicating that an input media file
is required, along with a brief usage hint.

Current behavior:
The current output does not clearly explain that an input file is missing.

Why this matters:
Clear CLI feedback improves usability for new users and helps avoid confusion
when CCExtractor is used in scripts or terminal-based workflows.

I have built CCExtractor locally and would be happy to work on a fix
if this improvement is approved.

[Drishtipixiee]

just checking in — I’m happy to work on this if it looks good to maintainers.
thanks!

[Akki2005]

Hi, thanks for opening this issue.

I tested this on a clean setup (WSL/Linux), starting from a fresh clone of the repository. When running ./ccextractor without providing an input media file, the output does not clearly indicate that an input file is required, which could be confusing for new users.

While setting this up, I also attempted a standard Linux build using the provided autotools flow (linux/autogen.sh → configure → make). On a clean tree, the build currently fails at the linking stage due to an unresolved Rust symbol (ccxr_update_logger_target), so I couldn’t fully test runtime behavior beyond this point.

That said, the UX concern raised here still seems valid: it would be helpful if the CLI explicitly reported a missing input file and showed a brief usage hint.

I’d be happy to work on a fix or investigate further if this improvement is considered useful.

[cfsmp3]

While setting this up, I also attempted a standard Linux build using the provided autotools flow (linux/autogen.sh → configure → make). On a clean tree, the build currently fails at the linking stage due to an unresolved Rust symbol (ccxr_update_logger_target), so I couldn’t fully test runtime behavior beyond this point.

If you are seeing a build problem and have a user reported UI problem you haven't seen yourself, which one do you think you should be working on :-)

[Drishtipixiee]

got it that makes sense 🙂 I agree the build issue is higher priority. I’ll try to reproduce and
investigate the unresolved Rust symbol (ccxr_update_logger_target) first
and report back with findings or a fix. Once that’s resolved, I can revisit
the CLI UX improvement. thanks!

[Akki2005]

That’s a fair point — thanks for clarifying.
My intent was mainly to confirm the CLI UX concern raised in the issue and offer help, not to redirect focus away from higher-priority build problems.