> - clean code (not obfuscated) Obviously agreed. But there are likely disagreements about what is "clean" and what is "obfuscated". Turning a oneliner sed into a 10-liner read/while/case/set loop is usually not an improvement in my book (as discussed previously). If you want to avoid forking a sed process while keeping the code clean, you'll probably want to first develop a library of sh functions that let you do things like `map' an operation over a list of things.
> It does NOT help to make a oneliner and 1000 users asks > themself: what does THIS line? [3] sed code can be inscrutable, yes, but a single `s'ubstitution is not, no matter how complex the regexp may be. This doesn't meant that a oneliner sed script is necessarily the best option, just that it's probably not the thing on which to concentrate. > But while we are at it: > - don't fork, if not needed. examples from /etc/init.d/compache: > [ "`cat /proc/swaps | grep 'ramzswap0'`" != "" ] && swapoff /dev/ramzswap0 That's an obvious one, yes. It's even a great contender for the Useless Use of Cat Award (http://partmaps.org/era/unix/award.html). > better use: > fgrep -q "ramzswap0" /proc/swaps || ... Yes, *much* better. I'd even call it a bug-fix (think of the day where /proc/swaps decides to start lines with a dash). > - use function_names to say what you want to do Agreed. > - use better shell builtins, instead of invoking another language > (e.g. awk, sed, lua) - only if there is no other option "No other option" is much too strong here: we want the code to be clean, first and foremost, so if the awk code is cleaner I'd much prefer we use it. > - using of shell builtins, leads to lower mem usage and are (mostly) faster Yes, but the shell's facilities are very primitive. Sometimes it's a bit like writing assembly code. Hence the need for a good library of shell functions that encapsulate the low-level code. > - make an official coding-style (at the moment much is mixed) Fine. Might prove difficult, but it's a worthy experiment. > - make an offical way, how to solve typical problems in scripts Seems to say the same as the previous point, so again: fine. > - make "base-files (experimental)" which can be selected in menuconfig > and i will maintain it. if people select it, they know the risk I'll let OpenWRT maintainers decide if it's a good idea. But I don't think it's particularly necessary: if you submit a patch which actually improves the code (e.g. the cat|grep thingy above), I see no reason to leave it in an "experimental" branch rather than in the normal files. OTOH, if there's disagreement over whether it's an improvement, then it just means it needs more work or should be dropped. Then again, maybe some of the changes can't be made incrementally. In that case, maybe a separate branch is in order. Stefan _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
