2019-06-18 10:32:45 +0100, Geoff Clare: [...] > There's no need to be so melodramatic. You are overstating the > consequences of shells changing to become conforming. They are > really quite minor, and mostly only affect badly written shell > scripts where the author forgot to quote something. The likelihood > of breaking a script that intentionally relies on current (except > bash5) shell behaviour, i.e. has a backslash in a filename pattern in > a shell variable that is expected to match an actual backslash in a > filename, is extremely small. [...]
If you want some examples, the autoconf "configure" script as used for instance to build bash is affected by the change where it now has one of those "time-bomb" bugs you were referring to. $ touch %sn $ bash5 ./configure checking build system type... x86_64-pc-linux-gnunchecking host system type... x86_64-pc-linux-gnun Beginning configuration for bash-5.0-maint for x86_64-pc-linux-gnu checking for gcc... gccnchecking whether the C compiler works... nonconfigure: error: in `bash5':nconfigure: error: C compiler cannot create executables See `config.log' for more detailsn Most of the scripts in the bash source distribution and many examples in the POSIX specification are what you call "badly written shell scripts" as they have unquoted parameter expansions (IIRC you once objected to fixing some of them on the ground that there was some text somewhere in the specification that said that $IFS was assumed to have a default value in the POSIX examples). Even the "bashbug" script shipped with bash to report bash bugs has an unquoted $TEMPDIR (which breaks in practice if $TMPDIR contains IFS characters but is unlikely to break if it has wildcard operators though, unless BASHOPTS=failglob or BASHOPTS=nullglob is in the environment). -- Stephane
