Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

cmp argument parser rewrite

オープン
#177 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
rust
領域
cli

調査の方向性

まず src/cmp.rs とリンクされた fork 内の提案版を確認し、引数解析、Params、ParamsParseError、help/version の処理、および一覧にあるオプション形式に注目します。既存の cmp テストと、fork に追加されたテストを確認します。パーサーの変更と公開 API に関する判断について合意され、サポートされるオプションとエラーが意図した動作と一致し、テストに合格すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Hello everyone,

I was checking the functionality of the cmp.rs and found some issues around not working options/arguments.

I did a lot of testing regarding the parser and found the following rules.

    /// Parses the command line arguments. \
    /// Since cmp is called from diffutils, the first argument must always be "cmp".
    ///
    /// The following checks require more extensive checks than a simple compare.
    /// These are all identical and make parsing extensive:
    /// - cmp file_1 file_2 -b -l -n 50
    /// - cmp file_1 file_2 -b -l -n50
    /// - cmp file_1 file_2 -bl -n50
    /// - cmp file_1 file_2 -bln 50
    /// - cmp file_1 file_2 -bln50
    /// - cmp file_1 file_2 --print-bytes --verbose --bytes 50
    /// - cmp file_1 file_2 --print-bytes --verbose --bytes=50
    /// - cmp file_1 file_2 --p --verb --by 50
    /// - cmp file_1 file_2 --p --verb --by=50
    /// 
    /// and many more rules.

A number of them are not working in the current cmp.rs version.

After I started to fix some of the issues, I started refactoring the whole parser.

  • Separation of concerns:
    • I moved all code regarding parsing into to Params struct.
    • The parser now only returns enums (Params or InfoText for Version and Help) for the OK case or a specified Error.
    • All errors have been moved into an Error Enum ParamsParseError which handles all output in Display.
    • This allows a centralized maintenance of errors and error messages. The caller can work with the error enum more easily.
  • Renaming of the Param properties.
    • from and to replaced with file_1 and file_2, as these are the parameters.
    • max_bytes with bytes_limit
    • quiet with silent as s is the short code for it
    • skip_a with ignore_initial_bytes_file_1, so there is a connection between options and the property name
  • The bytes variables where size usize, thus limiting the readable bytes on 32-bit systems. GNU cmp is compliles with
    Large File Support and allows i64 values. I changed it to u64 with a Feature to change it to u128.
  • bytes-limit: The tests set the bytes-limit to MAX:usize if a very large number is encountered. This is incorrect,
    GNU cmp gives an error message.
  • Corrected parser, e.g. -bln50KiB is now allowed or --ig for --ignore-initial
  • Correct output of error messages, Help text is missing. New error messages like in GNU cmp.
  • Added text for --version and --help
  • Tests
    • Added new tests for the above valid options.
    • Changed tests where bytes where set to MAX.
    • Tests not can be written with simple String "cmp foo bar -n 50"

Questions:

  • Params executable: What is the reason to store this value? It is the argument 'cmp' which is used to start the program.
    I don't see how this can ever change and it requires a lot of extra code to pass it to the error messages.
    const APP_NAME: &str = 'cmp'; would be sufficient, or am I missing something here? I would like to remove it.
  • GNU cmp behaves very odd when passing '--'. Try 'cmp -- file_1 --help'. Why whould --help be a file?
    I implemented an error message instead, as the usage is probably not intended.
    Is this an issue, as it would not behave 100% like GNU cmp. Try 'cmp -- file_1 --help'. Why whould --help be a file?
  • The error messages are slightly changed, e.g.
    • 'option requires an argument -- 'n'' when only passing -n, but
    • 'option '--bytes' requires and argument', which is nicer to read.
      I do not differentiate here and print:
    • 'option '--bytes' ('-n') requires an argument'
  • Params is generally public and could be used elsewhere, e.g. the number conversion. Should I keep it public?

Before submitting a PR I would like to have some feedback on this and the refactoring.

Check out the new version at my fork.

主要言語
Rust
スター
276
フォーク
39
平均マージ
3時間 27分
マージ済み PR(30日)
3

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

uutils/diffutils のほかの issue

uutils/diffutils の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。