Description of problem: Some init scripts, especially network, attempt to grep parameters out of what are otherwise source'able shell scripts. Version-Release number of selected component (if applicable): initscripts-8.60-1 How reproducible: Always Steps to Reproduce: 1. read /etc/rc.d/init.d/network Actual results: 1. Not a good look Expected results: 1. Should be better Additional info: At various points in 'network' there are lines such as "eval $(LANG=C fgrep "DEVICE=" ifcfg-$i)" and worse with grep/sed. Too bad if ifcfg-ppp1 might source ifcfg-ppp or similar. Scripts such as ifup very clearly source these config files as shell scripts (see source_config()). Why should 'network' goes its own way and handle them differently? Is "eval $(LANG=C fgrep "DEVICE=" ifcfg-$i)" really nicer than ". ifcfg-$i"? I don't think so. It is pointless, ugly, inaccurate, a hack, incredibly bad form, and totally unnecessary.
Having configurations include other configurations is not guaranteed to work, and never has been. Configurations aren't sources so that they can be found instead of polluting the environment, as doing otherwise involves playing tricks with subshells and pipes.
So why do ifup-* all invoke 'source_config()' which actually sources the config files as shell sources. If what you say is true, then you have exposed an enormous bug in all of those ifup-* scripts. They must be changed because of what you have just decreed. This bug can therefore be restated as: All ifup-* scripts must no longer invoke source_config() and must instead do some 'LC_All=C grep this and that' so as to conform to the better way of doing things. Viva la grep. Down with bash!
You misunderstood what I said, but thanks anyway. If you want to write a patch to source via a subshell and then pass the needed information back over a pipe (or whatever), go ahead. But configurations that directly include other configurations are *not* supported, any more than configurations that define and override functions used by the network scripts.