> - execline: I'd like the addition of a new command, e.g. readvar, that
> would allow to read the content/first line of a file into a variable.
> IOW, something similar to importas (including an optional default
> value), only instead of specifying an environment variable one would
> give a file name to load the value from (in a similar manner as to what
> s6-envdir does, only for one var/file and w/out actually using
> environment variable).
How about
"backtick -n SOMETHING { redirfd -r 0 FILE cat } import -U SOMETHING" ?
Sure it's longer, but it's exactly what the "readvar" command would do.
You can even program the "readvar" command in execline. ;)
If for some reason it's inconvenient for you, I can envision writing
something similar to readvar, but it *is* going to use the environment:
I've been trying to reduce the number of commands that perform
substitution themselves, so that passing state via the environment is
prioritized over rewriting the argv, and "import" is kind of the
one-stop-shop when you need substitution. I don't want to go back on
that intent and add another substituting command. Is it a problem for
you to use the environment ?
> - s6-log: I think a new action to write to a file could be useful.
The problem with that is the whole design of s6-log revolves around
controlling the size of your logging space: no uncontrolled file
growth. Writing to a file would forfeit that.
What I'm considering, though, is to add a "spawn a given program"
action, like a !processor but every time a line is selected and triggers
that action. It would answer your need, and it would also answer
Patrick's need without fswatch. However, it would be dangerous: a
misconfiguration could uncontrollably spawn children. I'll do that when
I find a safe way to proceed.
> Now, shouldn't thoose 2 simply be 1-s, since the NUL is already
> accounted for with sizeof? Or am I missing/misunderstanding something here?
I'm looking, I'm thinking, and I can't find a good reason why those
shouldn't be 1s.
... That means... all this time, s6-supervise has been reading from an
invalid memory location (the byte after the end of "/supervise/status") ?
Ouch. That one could have seriously hurt. Thanks for the bug-report.
(And valgrind never said anything. Bad, bad valgrind.)
--
Laurent
Received on Mon Jan 26 2015 - 22:18:33 UTC