Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Mike Frysinger Newsgroups: gnu.bash.bug Subject: Re: updating shopt compat settings to include current version Date: Thu, 15 Oct 2015 17:30:26 -0400 Lines: 132 Approved: bug-bash@gnu.org Message-ID: References: <20151015173433.GS4446@vapier.lan> <561FF051.8000001@case.edu> <20151015192704.GU4446@vapier.lan> <56200730.2060900@case.edu> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CJCg3p2l15m1juT/" X-Trace: usenet.stanford.edu 1444944678 1438 208.118.235.17 (15 Oct 2015 21:31:18 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Chet Ramey Envelope-to: bug-bash@gnu.org Mail-Followup-To: Chet Ramey , bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <56200730.2060900@case.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 140.211.166.183 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11670 --CJCg3p2l15m1juT/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 15 Oct 2015 16:06, Chet Ramey wrote: > On 10/15/15 3:27 PM, Mike Frysinger wrote: > > our build environment relies heavily on bash. in our ebuild standard, = we > > declare the min version of bash that is supported (3.2 currently). this > > way we don't have people using features found only in newer versions and > > breaking on systems with older versions of bash. >=20 > Wow. How many systems have bash-3.2? It is ten years old, after all. Do > you build and support new packages for old systems running bash-3.2? we support it -- if someone reports it. how many reports we actually get who knows. in practice, it means we disallow newer features like ${foo^^} and ${foo,,} that are easy to recognize, and we try to write code like=20 "${PV/_/'~'}" that'll work in both new and old versions. we're in the process of picking a newer version for the next standard. it'= ll be 4.2 or 4.3. but discussion for making upgrades less flaky shook out of = the discussion hence we looked at this compat logic. > > but when bash changes behavior on us (there are a variety of examples= =20 > > between 3.2 and 4.3), some > > ebuilds break because they expected bash 3.2 behavior but got something > > else. so every bash release ends up triggering a fire drill where we t= ry > > to weed out all the common issues (we have ~20k packages, and many have > > multiple versions). >=20 > Do you ever do any of this work with the alpha and beta versions? It > seems like there are months there when you could be addressing these > issues. yes, when you release alpha/beta versions ;), i add them to Gentoo. but de= vs have to explicitly opt into them. i do, and i know one or other people do,= but otherwise i'm not sure how much testing they see. i've reported at least one such issue already, and i'm pretty sure we've se= en some in the past that got fixed before the final. but the alpha/beta busin= ess is still somewhat new. > > even then, for a while people introduce bugs since > > they're running the new version only (or old version), and people notice > > because things break. then it settles down once everyone has moved to > > the same version. but i'm sure even today we add code that does not wo= rk > > under bash-3.2 (or some version between then and now), but most people = do > > not notice, and those who do aren't guaranteed to file bugs. >=20 > You could always just run bash-3.2 against your ebuild system, or run the > collection of scripts under bash-3.2, to test whether or not it works. that assumes that behavior changes only once between versions. pretty sure we've seen changes where bash-3.2 did one thing, bash-4.3 did something els= e, and versions in between did yet another thing. i don't recall exact exampl= es off the top of my head, but i *feel* like it has happened :). > > the bash compat feature seems to address this nicely: our standard says > > we should use bash-3.2, so we set the compat level to that, and then we > > have much stronger confidence in newer versions not breaking, or people > > adding code that only works on newer versions. >=20 > You should approach this with caution. I'm sure there are changes and bug > fixes that introduce incompatible behavior that are not addressed by the > compatNN variables. I guess as long as it doesn't bite you, you're ok. right. we're OK with reporting & getting those fixed. > > at any rate, it looks like the intention is to not do what we want, so > > we'll have to explicitly check the BASH_VERSINFO ourselves up front and > > deal with the various changes in compat selection. >=20 > Is it just the ebuild system or do you want to make sure every shell sets > compat32? only the ebuilds. we explicitly do not want external scripts getting screw= ed up. that's even more unmanageable :). > I mean, in theory, it's simple to do that: >=20 > unset BASH_COMPAT > shopt -u compat31 > command shopt -s compat32 2>/dev/null =2E.. but that doesn't work in bash-3.2: $ bash-3.2 -c 'shopt -s compat32' bash-3.2: line 0: shopt: compat32: invalid shell option name and it won't work when we updated to bash-4.2/4.3, or when you stop adding new compatXY options. -mike --CJCg3p2l15m1juT/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWIBrxAAoJEEFjO5/oN/WB0/wQAJNlPIZklZlreM4SH9WF8C6G BChi+7f7QHTAI93FSFWBt0mqdjUiHjYCTLQNvSs2NjVhTzrRJJ2vJ8sqrz7i2vzt F9POJpQQWI1DMFJ4sx/H5kkyYUBoYioOaW0xnQllFtrZCUCiR/3fd7W+QQWkzWaB Can422nhQ808YN1AKYCrZOV3jtxRaQPuMZiIBabhQniw/zye5TFVr4cGe8qq0Xp5 5FB5+OctjpBbUzvj7WW6agMjZRZ1YBFybyuW4OKL41hGtAlYNF1qDTXIBDCbWg66 XQnNavRfwRtj4hYFlCYFlkfssJoRn1m8k42OhDFEXmHWR/Ee1cQ/znVtrREQvkn9 bHkeeIaIOG8BNc2g17vYbiVEjJd9oJT3NveR9hucQYmDR7ulHQdefNW151ffRGBr IwSJyHx6PmTVLRmASIPGk+CVIoePmLHCHY1Qz8vtiJdlUv2qhkWV+pzqmK2+dhnp rIUDkd71OgeaOF7KkMThQziZzBFdc3zzy6zCBXK3uFKvWtCaKAZ7QIFrhc3A+zuQ PYxnIvYPDWWQrRu6TMsq9BWfFfFSgnXRyWrdhRs0jsX5KqxlHrr+n6UptFjBA1tZ 58CLCpgvuune1Uz4NRMewVF3LFb1kLFBwQdQGVsA4dKQl8ajI7vI+dh7KweHHlde ZqCEro03eYBOc+eujW2+ =Nye/ -----END PGP SIGNATURE----- --CJCg3p2l15m1juT/--