Red Hat Bugzilla – Bug 450427
bad grep'ing of network configuration scripts
Last modified: 2014-03-16 23:15:06 EDT
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):
Steps to Reproduce:
1. read /etc/rc.d/init.d/network
1. Not a good look
1. Should be better
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
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.