[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30814: Please increase the value of MAX_MON_WIDTH in ls.c

From: Pádraig Brady
Subject: bug#30814: Please increase the value of MAX_MON_WIDTH in ls.c
Date: Wed, 14 Mar 2018 11:40:31 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 13/03/18 17:06, Rafal Luzynski wrote:
> As we have introduced the support of nominative and genitive
> month names in glibc [1] and we are going to provide the updated
> locale data for Catalan language [2] it has been discovered [3]
> that the current limit of the maximum length of the abbreviated
> month name as displayed by "ls -l" will not work with the new
> data for Catalan.  It is obligatory to precede the month name
> with "de " (note: the space) so the abbreviated month names limited
> to 5 characters will be ambiguous and therefore unreadable:

It's a bit surprising that _abbreviations_ all need the "de " prefix,
but fair enough.

> de ma  (should be "de mar" at least)
> d’abr  (correct)
> de ma  (should be "de mai" at least)
> de ju  (should be "de jun" at least)
> de ju  (should be "de jul" at least)
> Increasing the value of MAX_MON_WIDTH to 6 characters will fix
> the problem. The location of the constant is here: [4]
> Although it has been also suggested in the same bug report that
> there should be no additional limit for the month length.
> This bug may be related with the coreutils bug #29377. [5]
> Regards,
> Rafal Luzynski
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=10871
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22848
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=22848#c6
> [4] http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c#n1099
> [5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29377

Thanks for the careful analysis.

5 was chosen as a max width for abmon
as that was seen to be unambiguous and
also truncate overly long abbreviations.

One can browse the abbreviations by length using:

  locale -a | grep utf8 |
  while read l; do LC_ALL=$l locale abmon; done |
  tr ';' '\n' | sort -u | grep '.\{5,\}' |
  while read mon; do
    printf '%02d %s\n' "$(echo "$mon" | wc -L)" "$mon"
  done |
  sort -n | less

That shows a couple of existing issues with the limit of 5.
ln_CD.utf8 (Democratic Republic of the Congo) needs a length of 7 to be 
while Arabic needs 12!
I don't remember arabic being so long at the time I implemented
the alignment/truncation in ls (9 years ago), but we should probably
expand to account for that.

$ LC_ALL=ln_CD.utf8 locale abmon

$ LC_ALL=ar_SY.utf8 locale abmon | tr ';' '\n'
كانون الثاني
تشرين الأول
تشرين الثاني
كانون الأول

Given the increase in supported size should only impact relatively few languages
it probably makes sense to increase to 12. The attached does that
and also augments the test to find ambiguous cases.


Attachment: ls-abmon-width.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]