ASAN: "ls -l, *" AddressSanitizer warning: "unexpected format specifier in printf interceptor: %*j'"

# ls -l, * /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/lib/libc/stdio/fread.c:133:10 in ==47404==AddressSanitizer: WARNING: unexpected format specifier in printf

Better color support in diff(1) and ls(1)

Hello,     I just submitted two differentials, D30545 and D30547, for color support in diff(1) and underline support in ls(1) respectively. While I was submitting these I also noticed that .arcconfig is still configured to submit differentials to the subversion repo, not the git one

Re: problem with ls, not show a correct list

On 09.04.2017 19:31, Nilton José Rizzo wrote: >try this > > ls [a-b,k-m] > >in sh using the locale setting to pt_BR.UTF-8 > > it's not work For the set below I got on -current a A b k K l m with any non-C locale wh

Re: problem with ls, not show a correct list

Em 2017-04-09 00:26, Andrey Chernov escreveu: On 07.04.2017 23:20, Nilton José Rizzo wrote: Em 2017-04-07 05:51, Toomas Soome escreveu: On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: Hi Allan, the ls show all files without case match ls [a-z]* show all files beg

Re: problem with ls, not show a correct list

On 07.04.2017 23:20, Nilton José Rizzo wrote: > Em 2017-04-07 05:51, Toomas Soome escreveu: >>> On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: >>> >>>> Hi Allan, the ls show all files without case match >>>> >>>>

Re: problem with ls, not show a correct list

Em 2017-04-07 05:51, Toomas Soome escreveu: On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: Hi Allan, the ls show all files without case match ls [a-z]* show all files beginning with a and A like this [aA-zZ]* No, last "Z" is not included. Look th

Re: problem with ls, not show a correct list

In article <3a8b8ade882d1486aa41b448a9c83...@i805.com.br> you write: > > > It's a terrible Is it a locale bug? Look! > >% locale >LANG=pt_BR.UTF-8 >% touch E >% ls -l [a-z]* >-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 E No, it's the specification

Re: problem with ls, not show a correct list

On 07.04.2017 11:51, Toomas Soome wrote: > >> On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: >> >>> Hi Allan, the ls show all files without case match >>> >>> ls [a-z]* >>> >>> show all files beginning w

Re: problem with ls, not show a correct list

> On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: > >> Hi Allan, the ls show all files without case match >> >> ls [a-z]* >> >> show all files beginning with a and A like this [aA-zZ]* > > No, last "Z" is not

Re: problem with ls, not show a correct list

> Hi Allan, the ls show all files without case match > > ls [a-z]* > > show all files beginning with a and A like this [aA-zZ]* No, last "Z" is not included. ___ freebsd-current@freebsd.org mailing list https://lists.fre

Re: problem with ls, not show a correct list

Em 2017-04-07 02:29, Garrett Wollman escreveu: In article <3a8b8ade882d1486aa41b448a9c83...@i805.com.br> you write: It's a terrible Is it a locale bug? Look! % locale LANG=pt_BR.UTF-8 % touch E % ls -l [a-z]* -rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 E No, it's the specifi

Re: problem with ls, not show a correct list

> On Apr 6, 2017, at 22:15, Ngie Cooper (yaneurabeya) > wrote: > > >> On Apr 6, 2017, at 21:28, Nilton José Rizzo wrote: > > … > >> [966] root@valfenda rizzo #locale >> LANG=pt_BR.UTF-8 >> LC_CTYPE="pt_BR.UTF-8" >> LC_COLLATE="pt_BR.UTF-8" >>

Re: problem with ls, not show a correct list

> On Apr 6, 2017, at 21:28, Nilton José Rizzo wrote: … > [966] root@valfenda rizzo #locale > LANG=pt_BR.UTF-8 > LC_CTYPE="pt_BR.UTF-8" > LC_COLLATE="pt_BR.UTF-8" > LC_TIME="pt_BR.UTF-8" > LC_NUMERIC="pt_BR.UTF-8" > LC_MONETARY="pt_BR.UTF-8" > LC_MESSAGES="pt_BR.UTF-8" >

Re: problem with ls, not show a correct list

= % pwd /home2/rizzo/tmp/teste % touch a % touch b % touch c % touch d % touch A % touch D % touch E % ls -l [a-z]* -rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 a -rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 A -rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 b -rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 c -rw-r--r--

Re: problem with ls, not show a correct list

Em 2017-04-07 01:33, Allan Jude escreveu: On 2017-04-06 23:12, Nilton José Rizzo wrote: Hi all Look this command on a FreeBSD -current % ls -d /usr/ports/[a-z]* /usr/ports/accessibility /usr/ports/math /usr/ports/arabic /usr/ports/misc /usr/ports/archivers /usr/ports/Mk /usr/ports/astro

Re: problem with ls, not show a correct list

On 2017-04-06 23:12, Nilton José Rizzo wrote: > Hi all > > Look this command on a FreeBSD -current > > % ls -d /usr/ports/[a-z]* > /usr/ports/accessibility /usr/ports/math > /usr/ports/arabic /usr/ports/misc > /usr/ports/archivers /usr/ports/Mk > /usr/ports/as

Re: problem with ls, not show a correct list

Em 2017-04-07 00:59, Ngie Cooper escreveu: On Apr 6, 2017, at 20:12, Nilton José Rizzo <ri...@i805.com.br> wrote: Hi all Look this command on a FreeBSD -current % ls -d /usr/ports/[a-z]* /usr/ports/accessibility /usr/ports/math /usr/ports/arabic /usr/ports/misc /usr/ports/archiver

Re: problem with ls, not show a correct list

> On Apr 6, 2017, at 20:12, Nilton José Rizzo <ri...@i805.com.br> wrote: > > Hi all > > Look this command on a FreeBSD -current > > % ls -d /usr/ports/[a-z]* > /usr/ports/accessibility /usr/ports/math > /usr/ports/arabic /usr/ports/misc > /usr/ports/

problem with ls, not show a correct list

Hi all Look this command on a FreeBSD -current % ls -d /usr/ports/[a-z]* /usr/ports/accessibility /usr/ports/math /usr/ports/arabic /usr/ports/misc /usr/ports/archivers /usr/ports/Mk /usr/ports/astro /usr/ports/MOVED /usr/ports/audio /usr/ports/multimedia % echo /usr/ports/[a-z]* /usr

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote: > I can reproduce it on a clean 11.0-BETA1 VM. > fixed in r302916. Will merge in 2 days in stable/11 Best regards, Bapt signature.asc Description: PGP signature

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote: > I can reproduce it on a clean 11.0-BETA1 VM. > > > 2016-07-09 9:03 GMT+08:00 Huang Wen Hui : > > > For some reasons, r302324 seems not include in 11.0-ALPHA6? > > > > 2016-07-09 8:52 GMT+08:00 Huang Wen Hui

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

Chinese locale problem is gone. >> >> Cheers >> Huang Wen Hui >> >> 2016-07-05 16:50 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>: >> >>> On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote: >>> > These 2 files can make ls su

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

d.org>: > >> On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote: >> > These 2 files can make ls suck: >> > >> > touch 火灾1 >> > touch 火灾2 >> > >> > 2 files start with 2 same Chinese chars. >> > >> I canno

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

Revert back r302324, Chinese locale problem is gone. Cheers Huang Wen Hui 2016-07-05 16:50 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>: > On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote: > > These 2 files can make ls suck: > > > > touch 火灾1 > >

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote: > These 2 files can make ls suck: > > touch 火灾1 > touch 火灾2 > > 2 files start with 2 same Chinese chars. > I cannot reproduce on my head laptop, neither on a clean 11.0-ALPHA6 jail. I'll try on a clean 11.0-AL

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

These 2 files can make ls suck: touch 火灾1 touch 火灾2 2 files start with 2 same Chinese chars. % lldb /bin/ls (lldb) target create "/bin/ls" Current executable set to '/bin/ls' (x86_64). (lldb) run Process 2185 launching Process 2185 launched: '/bin/ls' (x86_64) Enter Control+C:

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

rg>: > > > > > > > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote: > > > > > Hi, > > > > > On very recent CURRENT, ls can eat high CPU time when > > LANG=zh_CN.UTF-8 > > > > and > > > > > LC_AL

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

800, Huang Wen Hui wrote: > > > > Hi, > > > > On very recent CURRENT, ls can eat high CPU time when > LANG=zh_CN.UTF-8 > > > and > > > > LC_ALL=zh_CN.UTF-8: > > > > > > > > % uname -a > > > > FreeBSD mbp.gddsn.org.cn 11.0-ALPH

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

On Mon, Jul 04, 2016 at 02:36:11PM +0800, Huang Wen Hui wrote: > 2016-07-04 14:20 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>: > > > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote: > > > Hi, > > > On very recent CURRENT, ls can eat

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

2016-07-04 14:20 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>: > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote: > > Hi, > > On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8 > and > > LC_ALL=zh_CN.UTF-8: > > > > %

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote: > Hi, > On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8 and > LC_ALL=zh_CN.UTF-8: > > % uname -a > FreeBSD mbp.gddsn.org.cn 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #121 r302331M: Mon > Jul 4 10:47

ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

Hi, On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8: % uname -a FreeBSD mbp.gddsn.org.cn 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #121 r302331M: Mon Jul 4 10:47:27 CST 2016 r...@mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK amd64 top show: 4457 hwh

Re: /bin/ls formatting broken for non-C(?) locales

On Wed, Nov 25, 2015 at 06:31:16PM +0300, Andrey Chernov wrote: > On 25.11.2015 18:12, Andrey Chernov wrote: > > On 25.11.2015 17:35, Baptiste Daroussin wrote: > >>> BTW, array size looks suspicious: > >>> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX]; > >>> what MB_LEN_MAX doing

Re: /bin/ls formatting broken for non-C(?) locales

On 25.11.2015 18:12, Andrey Chernov wrote: > On 25.11.2015 17:35, Baptiste Daroussin wrote: >>> BTW, array size looks suspicious: >>> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX]; >>> what MB_LEN_MAX doing here? This constant is for multiple-bytes encoded, >>> not for wide

Re: /bin/ls formatting broken for non-C(?) locales

On 25.11.2015 17:35, Baptiste Daroussin wrote: >> BTW, array size looks suspicious: >> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX]; >> what MB_LEN_MAX doing here? This constant is for multiple-bytes encoded, >> not for wide chars. > Bad copy/paste sorry it should be

Re: /bin/ls formatting broken for non-C(?) locales

On Wed, Nov 25, 2015 at 04:34:17PM +0300, Andrey Chernov wrote: > On 25.11.2015 15:53, Baptiste Daroussin wrote: > > What I did for now is set max_month_width to -1 and in ls_strftime I > > fallback on > > the plain strftime meaning you keep localized information but the > > alignement is > >

Re: /bin/ls formatting broken for non-C(?) locales

s > > > > Also added the error checking for the return of wide chars functions. For > > now I > > haven't added fallback, suggestions welcome if needed. > > 1) For just 1 char in wcswidth(_months[i][j], 1); it is better to > use another function wcwidth(wab_month

Re: /bin/ls formatting broken for non-C(?) locales

On 25.11.2015 16:51, Baptiste Daroussin wrote: > wcslcat works like strlcat: > to quote the manpage: > "It will append at most dstsize - strlen(dst) - 1 characters." > So here with your version it will be n - wcslen(wab_months[i]) -1 > which won't fit what we want to do. > > btw that makes me

Re: /bin/ls formatting broken for non-C(?) locales

On 25.11.2015 15:53, Baptiste Daroussin wrote: > What I did for now is set max_month_width to -1 and in ls_strftime I fallback > on > the plain strftime meaning you keep localized information but the alignement > is > broken as of now. It will be enough. >> 3) wcwidth/wcswidth may return -1

Re: /bin/ls formatting broken for non-C(?) locales

On Wed, Nov 25, 2015 at 05:06:17PM +0300, Andrey Chernov wrote: > On 25.11.2015 16:51, Baptiste Daroussin wrote: > > wcslcat works like strlcat: > > to quote the manpage: > > "It will append at most dstsize - strlen(dst) - 1 characters." > > So here with your version it will be n -

Re: /bin/ls formatting broken for non-C(?) locales

On Wed, Nov 25, 2015 at 01:15:13AM +0100, Baptiste Daroussin wrote: > On Sat, Nov 21, 2015 at 11:57:46PM +0300, Andrey Chernov wrote: > > On 21.11.2015 15:18, Ed Schouten wrote: > > > Hi Baptiste, > > > > > > I suppose you should use the wcswidth() function somewhere to compute > > > the visible

Re: /bin/ls formatting broken for non-C(?) locales

On Sat, Nov 21, 2015 at 11:57:46PM +0300, Andrey Chernov wrote: > On 21.11.2015 15:18, Ed Schouten wrote: > > Hi Baptiste, > > > > I suppose you should use the wcswidth() function somewhere to compute > > the visible width of the month name. Some characters may be > > double-width, others may

Re: /bin/ls formatting broken for non-C(?) locales

For just 1 char in wcswidth(_months[i][j], 1); it is better to use another function wcwidth(wab_months[i][j]); 2) By fallback I mean something which not stops ls working with incorrect for some reason locale, like setting max_width_month to MAX_ABMON_WIDTH on error return (from mbstowcs/wcwidth/wcs

Re: /bin/ls formatting broken for non-C(?) locales

On 25.11.2015 4:31, Andrey Chernov wrote: > 4) The whole processing looks overcomplicated and not effective. What > about this instead? > for (i = 0; i < 12; i++) { > count wcswidth() of each month and store it in wab_months_width[]. > count max_width_month. > } > for (i = 0; i < 12; i++)

Re: /bin/ls formatting broken for non-C(?) locales

On 21.11.2015 15:18, Ed Schouten wrote: > Hi Baptiste, > > I suppose you should use the wcswidth() function somewhere to compute > the visible width of the month name. Some characters may be > double-width, others may have no effective width at all. > I agree. Checking error return of wide

Re: /bin/ls formatting broken for non-C(?) locales

Hi Baptiste, I suppose you should use the wcswidth() function somewhere to compute the visible width of the month name. Some characters may be double-width, others may have no effective width at all. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717

Re: /bin/ls formatting broken for non-C(?) locales

on head@r290573: > > > WTR: > > > env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env > > > LC_ALL=ru_RU.UTF-8 > > > ls -la /usr/ports/databases/ > > > env LC_ALL=C ls -la /usr/ports/databases/ works fine > > > also on old stable/10 (r286868)

Re: /bin/ls formatting broken for non-C(?) locales

On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote: > Hi, > > subj. http://i.imgur.com/F9QO29l.png > it is on head@r290573: > WTR: > env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=ru_RU.UTF-8 > ls -la /usr/ports/databases/ > > env

Re: /bin/ls formatting broken for non-C(?) locales

On Fri, Nov 20, 2015 at 11:42:53AM +0100, Baptiste Daroussin wrote: > On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote: > > Hi, > > > > subj. http://i.imgur.com/F9QO29l.png > > it is on head@r290573: > > WTR: > > env LC_ALL=uk_UA.UT

Re: /bin/ls formatting broken for non-C(?) locales

> > > > subj. http://i.imgur.com/F9QO29l.png > > > > it is on head@r290573: > > > > WTR: > > > > env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env > > > > LC_ALL=ru_RU.UTF-8 > > > > ls -la /usr/ports/databases/ >

Re: /bin/ls formatting broken for non-C(?) locales

g some internal encoding knowledge, they are wrong for non-UTF-8 encodings in any case, use wide chars instead. BTW, the same 3 chars restriction is in tar, cpio, pax, lots of ftp clients, i.e. where 'ls' emulated. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature

Re: /bin/ls formatting broken for non-C(?) locales

sd.org/D4239 > > The whole function is ugly, not only its name. Please no hardcoded > constants assuming some internal encoding knowledge, they are wrong for > non-UTF-8 encodings in any case, use wide chars instead. > > BTW, the same 3 chars restriction is in tar, cpio, pax, lots

/bin/ls formatting broken for non-C(?) locales

Hi, subj. http://i.imgur.com/F9QO29l.png it is on head@r290573: WTR: env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=ru_RU.UTF-8 ls -la /usr/ports/databases/ env LC_ALL=C ls -la /usr/ports/databases/ works fine also on old stable/10 (r286868) as I can see 'month' field length

Re: ls is broken for non-C locales due to libxo

On Jun 16, 2015, at 9:53 PM, Andrey Chernov a...@freebsd.org wrote: Should be no any %FF, but single char in pre libxo ls or nothing in post libxo one. Use LANG=ru_RU.KOI8-R before touch command. It looks like you create file with name %FF instead. No difference: fbsdvm64% env LANG

Re: ls is broken for non-C locales due to libxo

On Jun 17, 2015, at 9:35 AM, Andrey Chernov a...@freebsd.org wrote: Signed PGP part On 17.06.2015 16:58, Marcel Moolenaar wrote: On Jun 16, 2015, at 9:53 PM, Andrey Chernov a...@freebsd.org wrote: Should be no any %FF, but single char in pre libxo ls or nothing in post libxo one

Re: ls is broken for non-C locales due to libxo

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17.06.2015 16:58, Marcel Moolenaar wrote: On Jun 16, 2015, at 9:53 PM, Andrey Chernov a...@freebsd.org wrote: Should be no any %FF, but single char in pre libxo ls or nothing in post libxo one. Use LANG=ru_RU.KOI8-R before touch

Re: ls is broken for non-C locales due to libxo

a problem, provide me with a way to reproduce. touch `printf \377` env LANG=ru_RU.KOI8-R ls -l | od -bc | grep 377 fbsdvm64% touch `printf \377”` fbsdvm64% ls -l | head -2 total 96 -rw-r--r-- 1 marcel staff 0 Jun 16 21:25 %FF fbsdvm64% env LANG=ru_RU.KOI8-R ls -l | head -2 total 96 -rw-r--r-- 1

Re: ls is broken for non-C locales due to libxo

=ru_RU.KOI8-R ls -l | od -bc | grep 377 - -- http://ache.vniz.net/ -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJVgO2wAAoJEKUckv0MjfbKm94H/ic8hVCgYX1hFA6YAT8hksHF +RMrrus4iElF0Dz7sxx4q0CPBhIP2NPVXnNQZUeZwFHe4x/oFC7KYfZH6s74xoU3 AU1orszVWm2OhZ0RiB2CXnbxMhHyDm1gIRLm6sFtvE95SgDW0k1hg4Ym3tBfQOB1

Re: ls is broken for non-C locales due to libxo

to reproduce. touch `printf \377` env LANG=ru_RU.KOI8-R ls -l | od -bc | grep 377 fbsdvm64% touch `printf \377”` fbsdvm64% ls -l | head -2 total 96 -rw-r--r-- 1 marcel staff 0 Jun 16 21:25 %FF fbsdvm64% env LANG=ru_RU.KOI8-R ls -l | head -2 total 96 -rw-r--r-- 1 marcel staff 0 16

Re: ls is broken for non-C locales due to libxo

On 2015-06-16 23:23, Marcel Moolenaar wrote: On Jun 16, 2015, at 7:42 PM, Andrey Chernov a...@freebsd.org wrote: On 17.06.2015 5:18, Andrey Chernov wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national

ls is broken for non-C locales due to libxo

Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo

Re: ls is broken for non-C locales due to libxo

On Wed, 17 Jun 2015 05:18:35 +0300 Andrey Chernov a...@freebsd.org wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. ___ freebsd

Re: ls is broken for non-C locales due to libxo

On 17.06.2015 5:18, Andrey Chernov wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. I mean ls -l. To be precise, for 8bit non-C locales at least: ls -lt: skip date column

Re: ls is broken for non-C locales due to libxo

On Jun 16, 2015, at 7:42 PM, Andrey Chernov a...@freebsd.org wrote: On 17.06.2015 5:18, Andrey Chernov wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. I mean ls

Re: files disappearing from ls on NFS

3. ls - I see that it is moving 4 blocks 4k each to the user and they look fine 4. wait half an hour 5. ls - now there is only one block, which contains zeros starting from 0x200. Note that I don't do anything else on that machine during that time. RMSince you get valid data sometimes

Re: files disappearing from ls on NFS

(). So what I do: 1. reboot 2. login 3. ls - I see that it is moving 4 blocks 4k each to the user and they look fine 4. wait half an hour 5. ls - now there is only one block, which contains zeros starting from 0x200. Note that I don't do anything else on that machine

Re: files disappearing from ls on NFS

the data out of them. RMOne thing you might check via printf()s is whether the buffer cache RMhas the zero'd data in it before it copies it to userland. I now dump the data just before the call to vn_io_fault_iomove in ncl_bioread(). So what I do: 1. reboot 2. login 3. ls - I see that it is moving 4

Re: files disappearing from ls on NFS

(it seems only on NFS RM mounts): RM RM ls or RM RM even echo * will list only some files (strange enough the first RM files RM RM from RM RM the normal, alphabetically ordered list). If I change something RM in the RM RM directory (delete a file or create a new one) for some time the RM RM complete RM RM

Re: files disappearing from ls on NFS

). Now I see a strange effect (it seems only on NFS RM mounts): RM RM ls or RM RM even echo * will list only some files (strange enough the first RM files RM RM from RM RM the normal, alphabetically ordered list). If I change something RM in the RM RM directory (delete a file or create a new

RE: files disappearing from ls on NFS

and there to figure out... harti -Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Tuesday, May 14, 2013 2:50 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: On Mon, 13 May 2013, Rick Macklem wrote

RE: files disappearing from ls on NFS

Now I've also changed NFS_DIRBLKSIZ to 4k - no change. harti -Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Tuesday, May 14, 2013 2:50 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: On Mon

Re: files disappearing from ls on NFS

-Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Tuesday, May 14, 2013 2:50 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: On Mon, 13 May 2013, Rick Macklem wrote: RMHartmut Brandt

Re: files disappearing from ls on NFS

On Sun, 12 May 2013, Rick Macklem wrote: RMHartmut Brandt wrote: RM Hi, RM RM I've updated one of my -current machines this week (previous update RM was in RM february). Now I see a strange effect (it seems only on NFS mounts): RM ls or RM even echo * will list only some files (strange enough

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: On Sun, 12 May 2013, Rick Macklem wrote: RMHartmut Brandt wrote: RM Hi, RM RM I've updated one of my -current machines this week (previous update RM was in RM february). Now I see a strange effect (it seems only on NFS mounts): RM ls or RM even echo * will list

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first files from the normal, alphabetically ordered

Re: files disappearing from ls on NFS

: Re: files disappearing from ls on NFS RM RM Hartmut Brandt wrote: RM On Fri, 3 May 2013, Rick Macklem wrote: RM RM RMOk, if you succeed in isolating the commit, that would be great. RM RM Hmm. I'm somewhat stuck. clang from yesterday can't compile clang RM from RM a month ago... RM RM

RE: files disappearing from ls on NFS

; Andrzej Tobola Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: On Fri, 3 May 2013, Rick Macklem wrote: RMOk, if you succeed in isolating the commit, that would be great. Hmm. I'm somewhat stuck. clang from yesterday can't compile clang from a month ago... harti Oh well

Re: files disappearing from ls on NFS

04, 2013 11:33 PM To: Brandt, Hartmut Cc: curr...@freebsd.org; Andrzej Tobola Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: On Fri, 3 May 2013, Rick Macklem wrote: RMOk, if you succeed in isolating the commit, that would be great. Hmm. I'm somewhat stuck. clang

RE: files disappearing from ls on NFS

: files disappearing from ls on NFS Hartmut Brandt wrote: On Fri, 3 May 2013, Rick Macklem wrote: RMOk, if you succeed in isolating the commit, that would be great. Hmm. I'm somewhat stuck. clang from yesterday can't compile clang from a month ago... harti Oh, and one other thing you can

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: On Fri, 3 May 2013, Daniel Braniss wrote: DBI don't know about current, but on 9.1-stable, the nfsstat -m only works DBfor root! nfsstat can be run by anybody. Same for current. It silently prints nothing. Took me some time to figure out I should try as

Re: files disappearing from ls on NFS

wrote: RM RM Hi, RM RM RM RM I've updated one of my -current machines this week (previous RM update RM RM was in RM RM february). Now I see a strange effect (it seems only on NFS RM mounts): RM RM ls or RM RM even echo * will list only some files (strange enough the first RM files RM RM from RM RM

Re: files disappearing from ls on NFS

readdir for union mounts), since I can see that VOP_VPTOCNP() will also be broken without it. (I can't see how that would break ls, but it breaks __getcwd() and friends, so maybe it can affect ls somehow?) It's a cut/paste under windows, so I'm afraid the whitespace will be messed up, but it's pretty

Re: files disappearing from ls on NFS

(it seems only on NFS RM mounts): RM RM ls or RM RM even echo * will list only some files (strange enough the first RM files RM RM from RM RM the normal, alphabetically ordered list). If I change something RM in the RM RM directory (delete a file or create a new one) for some time the RM RM

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first files from the normal, alphabetically ordered

Re: files disappearing from ls on NFS

Brandt wrote: RM Hi, RM RM I've updated one of my -current machines this week (previous update RM was in RM february). Now I see a strange effect (it seems only on NFS mounts): RM ls or RM even echo * will list only some files (strange enough the first files RM from RM the normal, alphabetically

Re: files disappearing from ls on NFS

On Fri, 3 May 2013, Daniel Braniss wrote: DBI don't know about current, but on 9.1-stable, the nfsstat -m only works DBfor root! nfsstat can be run by anybody. Same for current. It silently prints nothing. Took me some time to figure out I should try as root... harti

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first files from the normal, alphabetically

Re: files disappearing from ls on NFS

Daniel Braniss wrote: Hartmut Brandt wrote: Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: On Fri, 3 May 2013, Daniel Braniss wrote: DBI don't know about current, but on 9.1-stable, the nfsstat -m only works DBfor root! nfsstat can be run by anybody. Same for current. It silently prints nothing. Took me some time to figure out I should try as root...

Re: files disappearing from ls on NFS

one of my -current machines this week (previous update RM was in RM february). Now I see a strange effect (it seems only on NFS mounts): RM ls or RM even echo * will list only some files (strange enough the first files RM from RM the normal, alphabetically ordered list). If I change something

Re: files disappearing from ls on NFS

Hartmut Brandt wrote: Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first files from the normal, alphabetically ordered

files disappearing from ls on NFS

Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first files from the normal, alphabetically ordered list). If I change something

Re: files disappearing from ls on NFS

...@dlr.dewrote: Hi, I've updated one of my -current machines this week (previous update was in february). Now I see a strange effect (it seems only on NFS mounts): ls or even echo * will list only some files (strange enough the first files from the normal, alphabetically ordered list). If I change

Re: files disappearing from ls on NFS

was in february). Now I see a strange effect (it seems FC only on NFS mounts): ls or even echo * will list only some files FC (strange enough the first files from the normal, alphabetically FC ordered list). If I change something in the directory (delete a FC file or create a new one) for some

Re: '/bin/ls' broken by SVN r226509

Daniel O'Connor docon...@gsoft.com.au writes: This is the crunched binary and is pretty big (unlikely to be an issue on a modern system though). You can do.. cd /usr/src/bin/ls make all install I think you missed the point. Reinstalling ls from broken sources wasn't going to help. He

Re: '/bin/ls' broken by SVN r226509

remind how to reinstall just /bin/ls, without the make buildworld? cp /rescue/ls /bin/ls oh.. of course. I've forgotten about /rescue. In fact, I only had to use it once before. This is the crunched binary and is pretty big (unlikely to be an issue on a modern system though

Re: '/bin/ls' broken by SVN r226509

Shterenlikht me...@bristol.ac.uk wrote: Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? cp /rescue/ls /bin/ls oh.. of course. I've forgotten about /rescue. In fact, I only had to use it once before. This is the crunched binary

Re: '/bin/ls' broken by SVN r226509

On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? cp /rescue/ls /bin/ls Cheers Tom ___ freebsd-current@freebsd.org mailing

Re: '/bin/ls' broken by SVN r226509

On Thu, Oct 20, 2011 at 11:58:41AM +0100, Tom Evans wrote: On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? cp /rescue/ls /bin/ls oh.. of course. I've

Re: '/bin/ls' broken by SVN r226509

On 20/10/2011, at 22:21, Anton Shterenlikht wrote: On Thu, Oct 20, 2011 at 11:58:41AM +0100, Tom Evans wrote: On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld

  1   2   >