-
Notifications
You must be signed in to change notification settings - Fork 695
Open
Description
This being 2025, I would expect that CLI programs that read non-interactive input and write non-interactive output (e.g. not done at an interactive prompt) to support STDIN and STDOUT respectively.
Granted, one can do e.g.:
cat generator.yml | \
snmp_exporter_generator generate \
-m mibs \
-g /dev/stdin \
-o /dev/stdout \
2>/tmp/err.out
to accomplish this, and it of course does work (for now), but:
- This is hacky at best (it's certainly inelegant)
- It is prone to breakage if
snmp_exporter_generator
ever starts printing to STDOUT during execution- (If implemented via proper switch arg parsing/pipe detection, e.g.
-o -
, that can trigger a specific global boolean that would suppress writing to STDOUT)
- (If implemented via proper switch arg parsing/pipe detection, e.g.
- I suspect non-seasoned/newbie Linux administrators to not even know the above is possible.
Thus, I suggest the following behavior instead:
-g somefile.yml
(or--generator-path="somefile.yml"
) should use the definedsomefile.yml
, regardless of STDIN.-g
or--generator-path
(no value provided) uses the defaultgenerator.yml
, regardless of STDIN.-g -
(or--generator-path="-"
) forces reading from STDIN.- If no
-g
or--generator-path
is specified, then:
Similarly, for for -o
/ --output-path
:
-o somefile.yml
(or--output-path="somefile.yml"
) should use the definedsomefile.yml
, regardless of STDOUT.-o
or--output-path
(no value provided) uses the defaultsnmp.yml
, regardless of STDOUT.-o -
(or--output-path="-"
) forces writing to STDOUT.- If no
-o
or--output-path
is specified, then:- If
os.STDOUT
is a pipe or redirect (see here -- basically the same as above should work, just operating onos.Stdout
instead ofos.Stdin
), use STDOUT as the write destination. - If it is not detected, use the default
snmp.yml
.
- If
Metadata
Metadata
Assignees
Labels
No labels