This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: dash-

On 2017-03-02 07:29, Eric Blake wrote:
> On 03/02/2017 07:36 AM, Marco Atzeri wrote:
>> On 02/03/2017 13:36, Steven Penny wrote:
>>> On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote:
>>>> Then you haven't been paying attention. And I didn't even
>>>> attempt to make an argument one way or the other, except to say
>>>> stop arguing. The horse is dead.
>>> Perhaps you could link to a constructive, concrete idea against
>>> the change that someone has made besides Eric. Even better, you
>>> could post your own constructive idea; surely you havent emailed
>>> twice now with nothing constructive to add?
>> He was constructive, but you seems biased in understanding the answer.
> To reiterate my answer in different terms:
> If you can convince Fedora to switch /bin/sh to dash, then I will
> immediately follow in Cygwin.  Until then, I'm worried that there are
> enough scripts in the wild that use bashisms and will therefore break if
> /bin/sh is not bash, even though that number has reduced somewhat since
> Debian made their switch.  Trying to make Cygwin the guinea pig, instead
> of Fedora, is going about it backwards (you WANT the change to be done
> in a place where there is plenty of manpower to deal with the fallout,
> and Fedora has more manpower than Cygwin).

I can see distros like *BSD or Debian making decisions like that or 
systemd, but not vendors like RH or Canonical: too little upside with 
too much downside for paying customers.

> I'm still toying with the idea of doing a test release of both bash
> and dash that flips /bin/sh between them; but I'm still stuck on the
> problem that a user MUST upgrade (or downgrade) both packages in
> tandem, or else risk being left without a /bin/sh at all. Help would
> be appreciated in figuring out the problem (telling me that "dash is
> faster than bash" is not help, nor is telling me that "portable shell
> scripts don't care if /bin/sh is bash or dash" - I already know those
> points. What I don't know is how many non-portable scripts are out
> there, so how much breakage would I be causing by forcing those
> non-portable scripts to deal with their non-portability, and how to
> minimize the even-worse breakage of an upgrade scenario that leaves
> no /bin/sh at all).

summary of checkbashisms -f run on 140 POSIX shell scripts as 
identified by file in my Cygwin 64 /bin/ with 784 packages (about 20% 
of cygwin-pkg-maint, 8% of setup.ini) installed, 70 possible issues 
(some from wrapped scripts because of -f): 
     14 /bin/cronbug
      7 /bin/procmail-config
      5 /bin/ca-legacy
      4 /bin/pcdovtoppm
      3 /bin/ppmshadow
      3 /bin/ppmfade
      3 /bin/fig2ps2tex
      3 /bin/bzgrep
      2 /bin/ppmrainbow
      2 /bin/pnmquant
      2 /bin/pnmflip
      2 /bin/install-catalog
      1 /bin/zgrep
      1 /bin/zdiff
      1 /bin/xzdiff
      1 /bin/updatedb
      1 /bin/texi2dvi
      1 /bin/ppmquant
      1 /bin/pnmquantall
      1 /bin/pic2graph
      1 /bin/pgmcrater
      1 /bin/pdfroff
      1 /bin/messagebus-config
      1 /bin/gzexe
      1 /bin/grap2graph
      1 /bin/gettextize
      1 /bin/
      1 /bin/eqn2graph
      1 /bin/clisp-link
      1 /bin/ccmakedep
      1 /bin/autopoint
      1 /bin/autoconf-2.69

with diagnostics (some from wrapped scripts because of -f):
     16 echo -e
     12 '((' should be '$(('
      7 alternative test command ([[ foo ]] should be [ foo ])
      7 $RANDOM
      6 unsafe echo with backslash
      5 'function' is useless
      4 type
      4 bash arrays, ${name[0|*|@]}
      3 ${parm/?/pat[/str]}
      3 $_
      1 should be '.', not 'source'
      1 $(OS|MACH)TYPE

So about 20% of packages have scripts installed, with potential issues 
ranging from 5-12*70 == 350-840.
Some potential fixes are obvious from my sample (attached, hopefully 
as inline text which will pass thru the filters): 

- change these scripts to shebang #!/bin/bash 
- replace echo -e with printf in most cases
- replace [[ ... ]] with [ ... ] or case if patterns are used 
- strip leading function 
- use  mktemp to eliminate $RANDOM

but most require judgement in application.

Generated scripts like libtool{,ize} may require complex patches submitted 
upstream to fix what may be sh dependent code generation or execution; not 
included in the attached sample, as file categorized these as:
/bin/libtool:    POSIX shell script, ASCII text executable, with very long lines, with escape sequences
/bin/libtoolize: POSIX shell script, ASCII text executable, with very long lines, with escape sequences

> Hmm, maybe I could create a NEW package, 'sh', which packages /bin/sh as
> however I want it (probably bash to begin with, to at least give people
> time to upgrade and pick up the packaging change before also having to
> deal with any shell changing). New releases of both bash and dash would
> depend on the new package, to guarantee that if you upgrade one shell,
> you pick up the dependency.  And by not having /bin/sh in either the
> bash or dash package, then we would at least avoid the current situation
> where upgrading/downgrading in the wrong order could leave a user
> without /bin/sh at all.  You might still be in a situation where the
> wrong version of the 'sh' package leaves you with an outdated version of
> a shell, or the wrong flavor in relation to the current distro choice,
> but that's less of a problem than having no /bin/sh at all.  In fact,
> having a separate 'sh' package may make it even easier to pick which
> shell flavor you prefer (if I always keep the 'curr' and 'test' versions
> pointed to different shells, then you make the choice of which sh flavor
> you want by which version you install).

Smart idea: just a postinstall dash script dependent on the prereq shell, 
ln curr bash->sh, test dash->sh, and respective man 1 page.

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Attachment: root-bin-shell-posix-bashisms.txt
Description: Text document

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]