|
From: Matthias A. <mat...@gm...> - 2007-03-17 20:42:40
|
Jochen Hayek schrieb:
> Now that we (the fetchmail community) know this, fetchmail can also get an internal
>
> putenv("SOCKS_CONF=/dev/null")
>
> somewhere around its
>
> SOCKSinit("fetchmail");
>
> and than a command line switch (e.g. --socks_conf=/etc/socks.conf )
> in order to change it back,
> so that somebody, who really wants to employ socks, actually makes use of it:
>
> putenv("SOCKS_CONF=/etc/socks.conf")
>
> But there are dozens of alternatives ...
But why would fetchmail then need its own command line switch at all?
I mean - if the SOCKS library reads the environment, we can just
document this. I'll do that now.
I'm not going to change the default behaviour in 6.3.X releases anyways:
incompatibilities do not belong in patchlevel update releases. So no
putenvs without options.
Adding even more code to handle yet another option however doesn't seem
justified in this case -- this new option would just be one different
formulation for exactly the same purpose - and we already have env(1)
and shells to handle this. It's not the putenv, but the dozens of code
lines in the fetchmail dump, option parser, rcfile parser, fetchmailconf
and everywhere else I've forgotten.
I hope that's acceptable.
If it's not, please find some good excuses for me for duplicating the
environment modification code that is already in env(1) - and please one
that keeps compatibility with 6.3.7. :-)
Best,
MA
|