On Tue, 12 Dec 2017 12:44:03 +0000, Todd C. Miller wrote: > On Tue, 12 Dec 2017 11:57:58 +0000, kshe wrote: > > > Perhaps the worst part of all this, though, is how the change of > > behaviour, which made sed fail hard where it previously handled input in > > a perfectly defined and reasonable way, was apparently approved because > > "implementations do vary in how they handle [it], so throwing an error > > is probably best". Following the same kind of reasoning, I think > > OpenBSD should also modify the `echo' command to fail if given an > > argument like `-E', as its behaviour in that case differs from system to > > system, hence the current implementation is likewise "just creating a > > trap for the user", and surely this is unacceptable and therefore ought > > to be fixed, right? > > It's not really the same situation. The question is what to do in > cases where POSIX leaves the behavior undefined and where there is > no consensus among implementations. Is it best for sed to be as > consistent as possible, knowing that other commonly used implementations > will produce different results, or is it better to produce an error > for the unwary user? This is not just theoretical, we run into > issues all the time with scripts that "work fine" on Linux but fail > in odd ways on other systems that don't use the GNU utilities. > > Most users will have no way to determine the source of the problem. > At least if the undefined behavior results in an error they have > something to go on.
Trying to prevent the unwary user from being unwary is a noble but impossible task to accomplish. There are so many ways to introduce non-portability in shell scripts that replacing historical behaviour by hard failures in an attempt to improve this situation is likely to be counterproductive, especially when such attempt goes against the internal consistency of the affected commands. Regards, kshe
