On 02/26/15 18:43, Laurent Bercot wrote: > > 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.
I get it. Although the option to use a clean environment feels (to me) like it belongs to s6-envdir, otherwise we can't guarantee that the environment we'll get won't be polluted from the original one. Yes, emptyenv allows do do that, but that's a little besides the point. It's not like there aren't more than one way/tool to do the same thing already, exec also allows to clear the environment after all. I don't feel strongly about it that I'll push this anymore, but just saying I feel this option makes sense on its own, not just to reduce the number of executable to call, but because s6-envdir is used to define an environment, having a way to guarantee what said environment will be seems a good/logical thing. > - 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. But you're missing one thing here: I don't want to simply add a prefix, I want to do that *after* the whole selection bit happened, and so conditionally. Otherwise I'd then need to maintain the regex to identify the lines in both locations: service logger (s6-log) to send the line to stdout/fifo, and then in the service reading from that fifo to determine what line this is/prefix to use. I would really like to avoid this. A simple sed one-liner makes sense only if I know what the line is. In s6-log I do, because it was selected via regex already, but with an external service I don't and need to re-implement that whole step again... So if sed can work it's certainly not a one-liner anymore. As an example: imagine the service is openvpn. I want the logger to log everything of course, but also id lines for when the connection is established (vpn is up/service is ready), and when it's down (vpn is down/service is not ready anymore, though still up ofc). This can happen many times over the life of the service, and I want to have a specific event/trigger when it goes up (ready), and another one when it goes down (non-ready). In s6-log I can select each line via regex and send both to some fifo (via 1), but if I didn't add a prefix I don't know which event this is. Now I could of course send all lines to that fifo and do the selection there, but then we're saying s6-log's selection feature is useless, and needs to be reimplemented elsewhere to be used? The prefix directive was a simple way to benefit from the selection feature by giving control over the output (log line, prefixed log line, or only the prefix even). A more complete solution would be a processor indeed, but, as in Colin's example, that has to be an integrated part of/as a processor of s6-log to remain a simple one-liner and benefits from the regex selection feature. > 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. I get that, but one could say that it allows to fully benefit from the selection feature of s6-log. One could also point out that even you saw an interest in such a prefix, only making it hard-coded and required when using 2, and unusable when using 1. Maybe it would be simpler (and more powerful obviously) to have 1 and 2 behave exactly the same, only on fd 1 or 2 is all. No more special "s6-log: alert: " prefix for 2 only, because there's a (non-sticky, a-la timestamps) control directive to set a prefix, so one can decide which prefix to use if any, on 1 and/or 2, and of course while benefiting from the selection feature to use different prefixes as needed! (For extra bonus there's "P" which like "p" but only use the prefix, without the log line after it.)
