On 27/04/11 21:25, Jim Meyering wrote:
> Ari Pollak wrote:
>> I've been sitting on this for a few months expecting to finish it, but
>> still haven't found the time, so I'm just putting it out there now so
>> it isn't lost entirely. It's originally from Chandrakumar Muthaiah:
>> http://article.gman
Jim Meyering wrote:
> Bruno Haible wrote:
>> building coreutils 8.12 on a Linux 2.6.25.20, glibc 2.8 machine, "make check"
>> shows this line:
>>
>> SKIP: misc/tty-eof
>>
>> But unlike for the other tests that are skipped, there is no explanation why
>> it was skipped. I have to look into the mi
Jim Meyering wrote:
...
> Subject: [PATCH] tests: remove useless test: misc/pwd-unreadable-parent
>
> * tests/Makefile.am (TESTS): Remove misc/pwd-unreadable-parent.
> This test was misleading and useless (was always skipped).
> Inspired by a report from Bruno Haible: http://debbugs.gnu.org/8570
>
On 04/28/2011 02:27 PM, Alan Curry wrote:
>>> 000 d r w x r - x r - x . 2 5 r=
>>
>>>726478772d727278782d202e35327220=
>
> Did anyone else notice the '.' after the drwxr-xr-x part? I bet that's
> what's confusing pytho
Eric Blake writes:
>
> On 04/28/2011 12:34 PM, Jason Vas Dias wrote:
> > I do:
> >=20
> > $ ls --version | grep '[(]G'
> > ls (GNU coreutils) 8.12
>
> Thanks for the report.
>
> > $ ls -dl /. | od -cx
>
> od -cx is not always the best choice in formatting - it depends on the
> endianness of you
Paul Eggert wrote:
> Jason Vas Dias wrote:
> > $ ls -dl /. | od -cx
> > ...
> > 040 r 2 0 1 5 : 2 8 / . \n
> >2072303231203a3538322f200a2e
> > 056
> >
> > Please could the ls developer let me know if it 100% POSIXLY corre
tag 8578 notabug
close 8578
thanks
On 04/28/2011 12:34 PM, Jason Vas Dias wrote:
> I do:
>
> $ ls --version | grep '[(]G'
> ls (GNU coreutils) 8.12
Thanks for the report.
> $ ls -dl /. | od -cx
od -cx is not always the best choice in formatting - it depends on the
endianness of your machine si
On 04/28/11 11:34, Jason Vas Dias wrote:
> $ ls -dl /. | od -cx
> ...
> 040 r 2 0 1 5 : 2 8 / . \n
>2072303231203a3538322f200a2e
> 056
>
> Please could the ls developer let me know if it 100% POSIXLY correct
> that ls ap
forcemerge 8570 8577
thanks
On 04/28/2011 12:28 PM, Jason Vas Dias wrote:
> Hi - Having just built GNU coreutils-8.12 against GNU libc 2.13,
> coreutils SKIPS a test normally run as part of "make check"
> because "system getcwd() is buggy" :
> (after coreutils-8.12 'configure' and 'make -j2' suc
I do:
$ ls --version | grep '[(]G'
ls (GNU coreutils) 8.12
$ ls -dl /. | od -cx
000 d r w x r - x r - x . 2 5 r
726478772d727278782d202e35327220
020 o o t r o o t 4 0 9 6 A p
Hi - Having just built GNU coreutils-8.12 against GNU libc 2.13,
coreutils SKIPS a test normally run as part of "make check"
because "system getcwd() is buggy" :
(after coreutils-8.12 'configure' and 'make -j2' succeeds :)
$ make check
...
./misc/pwd-unreadable-parent: skipping test: can't use bu
Hi,
On 04/28/2011 10:42 AM, Syed Nizamuddin wrote:
I get the following error .
basename: invalid option -- b
Try `basename --help' for more information.
basename: missing operand
I have basename used as
CMDE=`\basename $0 .sh`
echo "$basename is $CMDE"
Doesn't o/p anything. Please
Try
CMD
retitle 8575 basename usage question
tag 8575 notabug
thanks
On 04/28/2011 02:42 AM, Syed Nizamuddin wrote:
> Hi,
>
> I get the following error .
>
> basename: invalid option -- b
> Try `basename --help' for more information.
> basename: missing operand
Thanks for the report. However, this is
Hi,
I get the following error .
basename: invalid option -- b
Try `basename --help' for more information.
basename: missing operand
I have basename used as
CMDE=`\basename $0 .sh`
echo "$basename is $CMDE"
Doesn't o/p anything. Please
--
Regards,
*Syed *
Bruno Haible writes:
> If printing a date is harder than assigning that date to a file, how is then
> "ls -l" doing it?
>
> $ coreutils-8.12-64bit/src/ls -l f*
> -rw-r--r-- 1 bruno users 48 31. Mär 01:57 foo1.c
> -rw-r--r-- 1 bruno users 244 31. Mär 01:57 foo.c
> -rw-r--r-- 1 bruno users 0 922
Bruno Haible wrote:
> Hi,
>
> building coreutils 8.12 on a Linux 2.6.25.20, glibc 2.8 machine, "make check"
> shows these lines:
>
> ./misc/pwd-unreadable-parent: skipping test: can't use buggy system getcwd
> SKIP: misc/pwd-unreadable-parent
>
> REPLACE_GETCWD is indeed 1, because the test fr
Hi Jim,
> That use of touch has to depend on the file system since it sets
> stat.st_mtime and stat.st_atime.
But why is (in 64bit mode) 'touch' accepting a date that 'date' rejects?
$ coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
0
$ coreutils-8.12-64bit/src/date -d @922
Bruno Haible wrote:
> Hi Jim,
>
>> That use of touch has to depend on the file system since it sets
>> stat.st_mtime and stat.st_atime.
>
> But why is (in 64bit mode) 'touch' accepting a date that 'date' rejects?
>
> $ coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
> 0
> $ co
Hi Paul,
> > $ ./coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
> > 0
> >
> > $ ./coreutils-8.12-32bit/src/touch -d @922337203685477580 future; echo $?
> > ./coreutils-8.12-32bit/src/touch: invalid date format `@922337203685477580'
> > 1
And the 'date' program's interpreta
Bruno Haible wrote:
> building coreutils 8.12 on a Linux 2.6.25.20, glibc 2.8 machine, "make check"
> shows this line:
>
> SKIP: misc/tty-eof
>
> But unlike for the other tests that are skipped, there is no explanation why
> it was skipped. I have to look into the misc/tty-eof.log file, there I f
Bruno Haible wrote:
> building coreutils 8.12 on a Linux 2.6.25.20, glibc 2.8 machine, "make check"
> shows these lines in 32-bits only (not in 64-bit builds):
>
> bigtime: skipped test: file system cannot represent big time stamps
> SKIP: du/bigtime
>
> The message suggests that it's a problem
21 matches
Mail list logo
