Paul Eggert wrote: > (if I'm understanding things correctly) > POSIX says that mv's behavior here depends on nl_langinfo's result and > nothing else.
That's not my understanding. http://www.opengroup.org/susv3/utilities/mv.html says that - The processing of user responses uses the LC_MESSAGES locale category. - If nl_langinfo(YESEXPR) is used, it uses the LC_COLLATE and LC_CTYPE locale categories. > > + /* First, look in the gnulib message catalog. */ > > + const char *translated_pattern = _(english_pattern); > > + if (translated_pattern == english_pattern) > > + { > > + /* The gnulib message catalog provides no translation. > > + Try the system's message catalog. */ > > + translated_pattern = nl_langinfo (nl_index); > > + if (translated_pattern == NULL || translated_pattern[0] == '\0') > > + /* Broken system. */ > > + translated_pattern = english_pattern; > > The overall idea seems sound, but shouldn't the code simply use the > nl_langinfo result, if nl_langinfo exists and returns a nonempty > string? On most systems, nl_langinfo provides worse localization that a gnulib messages catalog. The notable exception are glibc systems, with its support of dozens of locales - but on glibc systems, the gnulib replacement for rpmatch() is not used anyway. IMO, proper localized behaviour here is more important than consistency with badly localized system primitives. For example, on Cygwin, nl_langinfo(YESEXPR) will always return a result for English. If you test nl_langinfo(YESEXPR) before _("^[yY]"), how do test whether it's properly localized or not? Bruno
