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/gettext.sh 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 $BASH_SOMETHING 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