GNU bug report logs - #30814
Please increase the value of MAX_MON_WIDTH in ls.c

Previous Next

Package: coreutils;

Reported by: Rafal Luzynski <digitalfreak <at> lingonborough.com>

Date: Wed, 14 Mar 2018 00:08:01 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Rafal Luzynski <digitalfreak <at> lingonborough.com>, 30814 <at> debbugs.gnu.org
Subject: bug#30814: Please increase the value of MAX_MON_WIDTH in ls.c
Date: Wed, 14 Mar 2018 11:40:31 -0700
[Message part 1 (text/plain, inline)]
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 unambiguous,
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
sánzá1.;sánzá2.;sánzá3.;sánzá4.;sánzá5.;sánzá6.;sánzá7.;sánzá8.;sánzá9.;sánz10.;sánzá11.;sánzá12.

$ 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.

cheers,
Pádraig
[ls-abmon-width.patch (text/x-patch, attachment)]

This bug report was last modified 7 years and 67 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.