Aaronontheweb / Aaronontheweb/ShellSyntaxTree
Extract shared native argument fragment classification
まだ誰も着手していません。
- 主要言語
- C#
- スター
- 15
- フォーク
- 0
- 平均マージ
- 9分
- マージ済み PR(30日)
- 7
説明
Problem
PR #68 added equivalent native-argument fragment walks to the Bash and PowerShell parsers. Both implementations now collect contiguous lexer fragments, preserve the complete raw span and decoded value, detect opaque fragments, and safe-fail resolver-sensitive mixed quoting. Keeping those rules duplicated creates a drift risk when another fragment shape or shell is added.
This is not a request for a shared lexer or parser core. Bash and PowerShell must retain their shell-specific tokenization, quoting, recursion, and command semantics.
Proposed scope
Extract an internal shell-neutral classification result for one native argument assembled from parser-owned lexer fragments. Each parser adapts its own tokens into the helper and remains responsible for consuming the resulting token range.
The shared result should carry:
- the complete authored source span and raw value;
- the combined decoded logical value;
- whether any fragment is opaque or computed;
- whether all value fragments are literal;
- whether mixed literal and expandable fragments contain resolver-sensitive syntax;
- the first index after the consumed fragment run.
Non-goals
- Unifying the Bash and PowerShell lexers.
- Building a shared parser base class.
- Changing the public AST or parser APIs.
- Weakening
DynamicSkipbehavior for ambiguous mixed quoting.
Acceptance criteria
- Bash and PowerShell use one internal fragment-classification implementation.
- Shell-specific token adapters remain small and explicit.
- Existing
Raw,Value, source-span, path, andDynamicSkipbehavior remains unchanged. - The PR #68 adversarial corpus cases for quoted values, maximal fragment runs, unquoted prefixes, mixed literal syntax, and curl
@transformation remain green in both shells. dotnet build -c Release,dotnet test -c Release, and header verification pass.
Extraction trigger
Do this before adding a third shell or another native fragment rule. Until then, the current duplication is correct but carries maintenance cost.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
PR #68で導入されたBashとPowerShellのネイティブ引数フラグメントの走査を比較し、その後、引用符で囲まれた値、最大長の連続列、混在構文、curl @変換に関するそれぞれの敵対的コーパスケースを調査します。シェルに依存しない分類のみを抽出し、トークンアダプターとパーサーの動作は分離したままにします。dotnet build -c Release、dotnet test -c Release、およびヘッダー検証を実行します。両方のシェルで既存の動作がすべて引き続きグリーンであれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- bash, csharp, powershell
- 領域
- tooling
- issue の種類
- リファクタリング
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 48/100