Jailer: added the -h flag as a shorthand for --help

[seafoodfry]

Changes

Jailer: added the -h flag as a shorthand for --help.

Reason

This is a common convention - thought it would be useful.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• If a specific issue led to this PR, this PR closes the issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this
  PR.
• API changes follow the Runbook for Firecracker API changes.
• User-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.
• New TODOs link to an issue.
• Commits meet
  contribution quality standards.

---

• This functionality cannot be added in rust-vmm.

---

Additional Details

Tried to replicate the workings of the ArgParser by starting from

firecracker/src/jailer/src/main.rs

Lines 318 to 320 in e67b2be

	arg_parser
	.parse_from_cmdline()
	.map_err(JailerError::ArgumentParsing)?;

Which leads to

firecracker/src/utils/src/arg_parser.rs

Lines 320 to 323 in e67b2be

	pub fn parse_from_cmdline(&mut self) -> Result<()> {
	let args: Vec<String> = env::args().collect();
	self.parse(&args)

From there I tried to replicate the logic with this small script to see if this patch would work:

use std::env;                                                           
                                                                        
const ARG_SEPARATOR: &str = "--";                                       
const HELP_ARG: &str = "--help";                                        
const SHORT_HELP_ARG: &str = "-h";                                      
                                                                        
fn split_args(args: &[String]) -> (&[String], &[String]) {              
    if let Some(index) = args.iter().position(|arg| arg == ARG_SEPARATOR) {
        return (&args[..index], &args[index + 1..]);                    
    }                                                                   
                                                                        
    (args, &[])                                                         
}                                                                       
                                                                        
fn parse(args: &[String]) {                                             
    // Skipping the first element of `args` as it is the name of the binary.
    let (args, _) = split_args(&args[1..]);                             
                                                                        
    if args.contains(&HELP_ARG.to_string()) || args.contains(&SHORT_HELP_ARG.to_string()) {
        println!("found help args: {args:?}");                          
    }                                                                   
}                                                                       
                                                                        
fn main() {                                                             
    let args: Vec<String> = env::args().collect();                      
                                                                        
    parse(&args)                                                        
}

I tried it out and saw the following:

➜  ~/src/temp/args_help git:(master) ✗ ./target/debug/args_help --help 
found help args: ["--help"]
➜  ~/src/temp/args_help git:(master) ✗ ./target/debug/args_help -h    
found help args: ["-h"]
➜  ~/src/temp/args_help git:(master) ✗ ./target/debug/args_help --helpo
➜  ~/src/temp/args_help git:(master) ✗ ./target/debug/args_help --h    
➜  ~/src/temp/args_help git:(master) ✗ ./target/debug/args_help -hello

So it seems like this "should" work.

[roypat]

Hi @seafoodfry,
thanks for the suggestions :) I think if we want to go with this, we should mention it in CHANGELOG.md. More importantly though is figuring out how to tighten up the parsing to avoid false-positives.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.34%. Comparing base (18a2a05) to head (c0e4fe8).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4743   +/-   ##
=======================================
  Coverage   84.34%   84.34%           
=======================================
  Files         249      249           
  Lines       27460    27460           
=======================================
  Hits        23160    23160           
  Misses       4300     4300           

Flag	Coverage Δ
5.10-c5n.metal	84.56% <100.00%> (ø)
5.10-m5n.metal	84.55% <100.00%> (ø)
5.10-m6a.metal	83.83% <100.00%> (-0.01%)	⬇️
5.10-m6g.metal	80.91% <100.00%> (ø)
5.10-m6i.metal	84.54% <100.00%> (+<0.01%)	⬆️
5.10-m7g.metal	80.91% <100.00%> (ø)
6.1-c5n.metal	84.56% <100.00%> (ø)
6.1-m5n.metal	84.55% <100.00%> (ø)
6.1-m6a.metal	83.83% <100.00%> (-0.01%)	⬇️
6.1-m6g.metal	80.91% <100.00%> (ø)
6.1-m6i.metal	84.54% <100.00%> (ø)
6.1-m7g.metal	80.91% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[roypat]

Looks good, I guess the only thing CI is complaining about is the newline in the changelog file

feedback addressed

[roypat]

Could you squash your two commits into one? That's also no need to list me as a co-author, I was just repeating what the CI was saying :)

[seafoodfry]

Could you squash your two commits into one? That's also no need to list me as a co-author, I was just repeating what the CI was saying :)

Deal and done. ptal!

And I think i'm getting the hang of contributing here (when to squash commits and when not to).
But, again, thank you for the reviews and for your patience @roypat !

[roypat]

Could you squash your two commits into one? That's also no need to list me as a co-author, I was just repeating what the CI was saying :)

Deal and done. ptal!

Thanks! Looks good now :)

And I think i'm getting the hang of contributing here (when to squash commits and when not to). But, again, thank you for the reviews and for your patience @roypat !

Based on your experience, do you think there's anything we could clarify in our documentation about it, to make it easier for the next contributor? :o

[roypat]

(also sorry for the PR cross-ref to rust-vmm, I messed up while copy-pasting >.>)

[seafoodfry]

Based on your experience, do you think there's anything we could clarify in our documentation about it, to make it easier for the next contributor? :o

Right now the only thing that comes to mind is something along the lines of "be diligent about squashing commits when implementing suggestions/fedbacks from PR reviews".
But i'm keeping this on my notes while I learn the cod. Hopefully after some more nontrivial PRs I'll get a better idea.