On Tue, 12 Feb 2019 08:34:00 +0100, "Dr. Werner Fink" <werner@suse.de> wrote:
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.
Maybe going into the area of being off-topic, but be careful to not being too enthusiastic here and do this for non-kernel distribution build packages (like LibreOffice or other open-source projects that live beyond Linux) Having developers optimize their build procedure to use the tools and features that are available in the "default" Linux world cause real big pain for OSS porters on different systems like HP-UX, AIX, Solaris etc Projects that require features - like bash functionality - that is not available on those proprietary OS's will cause the support on those OS's to halt. e.g. • GNU gcc is by now impossible to build on HP-UX. • Projects that switch(ed) to meson/ninja won't build outside Linux • Projects that require new(er/est) gcc won't build on OS's that won't build gcc I know that OSS developer time is "free" time and voluntary work, but remember that choosing the tool-of-the-day will cause headaches for those that use their free time to port OSS to those OS's that are not mainstream anymore. Story from the past: we had to switch from SCCS to something more recent. The team chose SVN. Our main development environment by the time was HP-UX 11.23, and we had to give up on SVN: we needed a week to build SVN from scratch with all its dependencies only to see it horribly fail. We then decided to try git. We just needed 3 hours to get it up and running, including the GUI's. *I* do not regret this, as I had a preference of git over svn from the start, and by now all our developers are used to git/gitlab and it is part of daily routine. If bash were to switch from make to meson/ninja, you'd rule out the use of modern bash on those weird OS's, as bash still is relative easy to build/port. (and so is "make") -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/