> >>>>> FreeBSD and Dragonfly BSD have this option in tr. So, this actually > >>>>> improves portability. > >>> > >>> It's just spreading the disease. portable means it works everywhere. > >>> Increasing the number of people who can write nonportable code is not > >>> the same as increasing portability. > >> > >> How many others have to adopt it before it's considered portable, then? > > > > It is portable when all of them have it. Since you can't fix the past, > > we must be very conservative in our approach. > > In this case `portable' simply means `unavailable'. And that's good. :) > DragonFly has it solely because of the shared FreeBSD history, not because > it's being used a lot.
We always face a mix of goals: - portability (for common tools, don't diverge unless value is high enough) - improvements (diverge if the value is high enough) - standards (when portability is mandated, strongly follow that) - defacto standards (non-official standards also exist) It takes a pretty big cry to start making changes. In part that is why this conversation isn't dead yet. It is quite telling that FreeBSD added it a long long time ago, and it has not been adopted elsewhere. Pushes back against the urgency. > >> It's possible, as mentioned elsewhere, that simply making tr be > >> unbuffered by default is the better move, and ignore -u for > >> compatibility with FreeBSD and Dragonfly BSD. > > How will that make things better? Standing alone, "compatibility with FOO" is not a very strong argument. What next, "compatibility with Xenix and Windows"?
