On Tue, Feb 12, 2019 at 07:09:18AM +0100, Michal Kubecek wrote:
On Tuesday, 12 February 2019 1:59 Simon Lees wrote:
Before this thread we hadn't considered looking at whether using a different #!/bin/sh would have a impact on builds particularly in the time it takes to execute configure or process makefiles under different shells, at some point in the next couple of months its now on my list to look at. Particularly in regards to packages like the kernel, libreoffice and chromium.
It certainly can. Few years ago, I was rather frustrated that when building a kernel package locally, more than 6 minutes out of total 35 was spent by brp-symlinks script. I was even considering to rewrite it to C and parallelize as a hackweek project.
Then Tomáš Čech tried, as an exercise, to rewrite the script just by replacing various invokations of sed, grep etc. with bash specific expansions. As a result, he managed to squeeze those 6 minutes down to ~30 seconds.
I can second this. Using bash builtins and string features can speed up scripts a lot. That is avoiding forking often for external command within loops, using <() fifo together with an external command to handle large lists of lines of strings at once and read the resulting lines with loops only using bash builtins. Also ksh93 loops can read from pipe (which is actual a combination of two socketpair()s) plus avoiding subprocess for the loop its self. But this is not portable to many bourne shell scripts as with ksh93 variables within the loop are visiable outside the loop. This can be an advantage but may break scripts depending on orignal bourne shell behaviour. The bash provides the <() fifo as a replacment for this. Then one can use the redirection operator to read from the <() fifo as stdin. -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr