Re: Feature requests for execline & s6
On 01/26/15 23:18, Laurent Bercot wrote:
>
>> - 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. ;)
That looks good, except that I need a default value, in case the file
doesn't exist. If there's a way to work a default value in that case
then that'd be fine, yes.
...is there a way to add a default value if FILE doesn't exist?
> 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 ?
No it's not, it just felt unneeded when thinking of readvar, is all. But
i could combine it with import, as I said what I really want is to have
a default value if the file doesn't exist, instead of nothing/empty
string, skipping/not using the environment was/is not a requirement at all.
>> - 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.
Yeah that would work for me... I thought the "writing to file" action
was maybe more "generic," but I get your point re: controlling the
logging size.
Running an external program would work for me just as well, yes. Looking
forward to this nice little addition.
(re: misconfiguration, in what way though? It could lead to the program
being triggered for each new line, but that doesn't mean uncontrollably
spawning children?
It might be a lot, but with a rotation every 4096 bytes one might
already have frequent calls to the processor, no?)
-j
Received on Mon Jan 26 2015 - 22:52:22 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:38:49 UTC