I fully agree with Colin on both points.
- For the s6-envdir thing: all the tools already exist to perform
what you want. Sure, adding an option isn't hard, and would make
things convenient, but it's a slippery slope. I try to provide
tools that perform basic operations and rely on users to combine
them to get the results they want. If I start adding options here
and there to minimize the number of executables you have to call,
what is convenience, what is redundancy, and what is outright
bloat ? Those are questions I'd rather not have to ask myself
all the time.
- For the s6-log thing: prepending a line with a string is
definitely work for a processor. A trivial sed one-liner at
that. If you need processing after s6-log has forwarded a
line, pipe it into another program.
Sure, the "p" option you're suggesting is a simple one, it
would be easy to implement, but then again, where to stop ?
Why limit ourselves to fixed strings ? Why not a more elaborate
format ? Slippery slope again - I'd rather draw the line
early and keep line modifications outside of s6-log.
(Timestamps are a special case. There's specific code to handle
them already and more line modifications would mean more
specific code.)
--
Laurent
Received on Thu Feb 26 2015 - 17:43:53 UTC