Hi Marc
On Wed, Aug 01, 2007 at 11:03:42AM +0200, Marc Haber wrote:
> On Wed, Aug 01, 2007 at 09:11:18AM +0200, Ola Lundqvist wrote:
> > On Tue, Jul 31, 2007 at 11:14:37PM +0200, Marc Haber wrote:
> > > Package: cron-apt
> > > Version: 0.4.14
> > > Severity: wishlist
> > > Tags: patch
> > >
> > > The attached patch modifies config.d semantics so that variables set
> > > in config.d are only honored for the corresponding action.d item while
> > > returning to the default read in from the config file for the next
> > > action.d item.
> > >
> > > This feels much more natural, to me at least.
> >
> > Hmm yes maybe. The problem however is that you can actually change any
> > variable in the config script... Should we store all found in env
> > and restore them after?
>
> I think that's too much. People are free to break their systems if
> they want to - it is already possible now. I have tried to implement
> the SAVE handling for the variables that I feel are important for
> cron-apt's function, but that list can of course be changed.
I actually think I have a solution for this... Isn't it possible to have
scopes in a POSIX shell? Like echo 1 | { ... }.
I tested with
SET1=1
SET2=2
SET3=3
echo 1 | {
echo "SET1: $SET1"
echo "SET2: $SET2"
echo "SET3: $SET3"
SET2=4
echo "SET2: $SET2"
}
echo "SET1: $SET1"
echo "SET2: $SET2"
echo "SET3: $SET3"
It seems to work as expected.
What we could do then is something like the following:
while action ... ; do
echo 1 | {
. config.dactionfile
runthing
}
done
Then we have full scope handling.
The drawback is that we will have a separate proces for each action, but
maybe that is ok?
> > > A different way to implement would mean having suffixes for the
> > > variable name in config.d, either FOO_FROMHERE to replace FOO's value
> > > for the rest of the cron-apt run, or FOO_HERE to only replace FOO's
> > > value for thi action.d item.
> >
> > That would be one way, but it seems rather complicated.
> > I think we should do something that is backwards compatible as well. :)
>
> So we'd need to go for the _HERE approach as directly changing the
> variables will still have the accustomed effect. I do, however, doubt,
> that anybody uses this mechanism yet - it is too hard to understand.
Maybe.
> > > Please indicate which way you'd prefer, and I'll send a modified
> > > patch. I do think that the patch listed above is the easiest one.
> >
> > I'm not sure what I prefer. :)
> >
> > Maybe I prefer the _HERE approach, but keep the old way that is if
> > you change SYSLOGON that is actually changed. So when restoring you
> > actually need to check if that the corresponding _HERE value actually
> > contain something.
>
> Yes, that would be my intention. Want me to deliver a patch?
Yes that would be nice.
Either some _HERE thing or scope handling as described above.
Before you make the patch, please tell me what you think about my idea about
the scope...
Regards,
// Ola
> Greetings
> Marc
>
> --
> -----------------------------------------------------------------------------
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
> Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
>
--
--- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| http://opalsys.net/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
