Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Can we assume that /bin/sh is bash?
On Tue, 12 Feb 2019 08:34:00 +0100, "Dr. Werner Fink" <werner@xxxxxxx>
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/
< Previous Next >
Follow Ups