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
