Pádraig Brady wrote: > Thanks for the detailed rationale, however > the existing env variables are significant to more utils than sort(1). > I.E. they're generally system level settings, rather than command level. > Also sort -S is very portable, even though not standardised. > solaris' sort(1) has -S and GNU sort is used on most other platforms, > which has -S available since TEXTUTILS-2_0_10-58-gbf86c62 > > Note also this thread on the selection of a default buffer size for pipes: > http://thread.gmane.org/gmane.comp.gnu.coreutils.general/878/focus=887 > > So currently I'd be 70:30 against adding such a variable.
Thanks for replying, Pádraig. Those are good points. Another is that we have a strong aversion to adding support for new environment variables in coreutils programs because it makes formerly-robust usage prone to malfunction or abuse. Imagine a script that worked fine before, but when someone ends up running sort with some unusual or extreme envvar setting that now makes that shell script's use of sort fail. With a new envvar as proposed, every sort-using script would have to be retrofitted with code to keep an erroneous or malicious envvar setting from impacting sort. Just say "No!" to new envvars ;-)