Engine messages hard-code CLI flag names; give them structured codes instead
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- go
调研方向
Start by reading the message strings in internal/scan/runner.go, options.go, scope.go, verdict.go, internal/dns/resolver.go and transport.go, then inspect the rewrite tables in pkg/subenum/subenum.go and their tests. The issue allows either structured codes and settings or neutral setting names, but replacing message parsing across engine and front ends is broad design work. Done means no engine message hard-codes CLI flags and the CLI, TUI and pkg/subenum each present settings in their own terms without parsing message text.
由索引模型根据 Issue 内容生成。
描述
Why it matters
Engine messages name command-line flags ("Use -force to scan anyway", "set -max-queries or -force", "concurrency (-t) must be at least 1"). That reads well in the CLI but is wrong anywhere else: the TUI has form fields, and pkg/subenum callers have Config fields, not flags.
Evidence
- About 40 flag references in message strings across
internal/scan/runner.go,options.go,scope.go,verdict.goandinternal/dns/resolver.go,transport.go. pkg/subenumworks around this with a regexp that rewrites-flagto the matchingConfigfield (flagFieldsandfieldNamesinpkg/subenum/subenum.go). It works and is tested, but a new message that names a flag missing from the table gets through unchanged.
Suggested approach
- Give events and validation errors a structured part: a code such as
wildcard_refusedorcap_reached, and the setting involved (force,max_queries). Each front end then writes its own wording. - Or, as a smaller step, have the engine refer to settings by neutral names and let each front end map them.
- Delete the regexp rewrite in
pkg/subenumonce the engine no longer writes flag names.
Done when
No engine message hard-codes a CLI flag, and the CLI, the TUI and pkg/subenum each name settings in their own terms without parsing message text.
- 主要语言
- Go
- 星标
- 1
- 派生
- 1
- 平均合并
- 5 天 2 小时
- 30 天内合并 PR
- 3
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
TMHSDigital/subenum 的其他 Issue
-
area: cli enhancement good first issue
难度 2/5 1-3 小时 新手友好度 88/100
TMHSDigital/subenum#136 ·
维护者通常 1 天内回复
-
community documentation good first issue
难度 2/5 1-3 小时 新手友好度 85/100
TMHSDigital/subenum#135 ·
维护者通常 1 天内回复
-
area: dns enhancement good first issue
难度 2/5 1 小时以内 新手友好度 90/100
TMHSDigital/subenum#134 ·
维护者通常 1 天内回复
-
community marketing priority: low
难度 5/5 一周以上 新手友好度 35/100
TMHSDigital/subenum#132 · 1 条评论 ·
维护者通常 1 天内回复
-
feature priority: low
难度 5/5 一周以上 新手友好度 35/100
TMHSDigital/subenum#131 ·
维护者通常 1 天内回复
查看 TMHSDigital/subenum 的全部 Issue
相似的 Issue
-
[schema-coverage] elasticstack_kibana_security_detection_rule可能已有人在做 @github-actions 今天认领。 未关闭acceptance-tests phase-coding schema-coverage testing triaged
难度 2/5 1-3 小时 新手友好度 65/100
elastic/terraform-provider-elasticstack#5186 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
jaegertracing/jaeger#9830 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
apache/rocketmq-dashboard#6318 ·
维护者通常 5 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
GoogleCloudPlatform/opentelemetry-operations-collector#710 ·
维护者通常 1 天内回复