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 |