John D. Ballentine III wrote:
> OK, I tried again from a fresh unpack of the tar file.
Good. It would otherwise have been a nagging concern that something
was wrong there.
> And, as suggested before, the HP make failed with yet another interesting
> series of messages:
>
> -g -O2 -c `test -f
Jeff Martens wrote:
> wc version 4.5.3 is produces the following error message:
Thank you for taking the time to report this problem.
> wc: /mnt/floppy/teaching.pdf:2447: Invalid or incomplete multibyte or wide character
>
> wc is supposed to count lines, words, and bytes, and so should not
> ev
Hello,
wc version 4.5.3 is produces the following error message:
wc: /mnt/floppy/teaching.pdf:2447: Invalid or incomplete multibyte or wide character
wc is supposed to count lines, words, and bytes, and so should not
even be aware that it's reading multibyte characters. Thus, this
error message
Jim> info coreutils nice
Uggg. man nice == man 1 nice, you need to say man 2 nice to get
nice(2)... Info should also get the more simpleminded choice too by default.
Jim> I've made this change:
nice :-)
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
h
OK, I tried again from a fresh unpack of the tar file.
And, as suggested before, the HP make failed with yet another interesting
series of messages:
-g -O2 -c `test -f 'human.c' || echo './'`human.c
human.c: In function `adjust_value':
human.c:111: parse error before `l'
human.c:114: `u' undecl
Thanks for the patches to coreutils-5.1.2 to fix the problem with the
zero nanosec values in output from stat. They work nicely:
Old:
% /usr/local/bin/stat --version
stat (coreutils) 5.1.2
% /usr/local/bin/stat /bin/true
File: `/bin/true'
Size: 312
[EMAIL PROTECTED] wrote:
> I'm using Red Hat Linux 7.2 and just updated the textutils package from
> version 2.0.14 to 2.0.21, but the error "csplit: memory exhausted" is
> still occurring intermittently in a shell script. Mostly it fails,
> sometimes it works.
[I've redirected to the bug-coreuti
Jim Meyering <[EMAIL PROTECTED]> wrote:
> It might even be worthwhile to interpret `\n', \t, \\, etc.
With bash, at least, users can do:
$ stat --format=$'%i\n' file
This seems like the sort of thing that is better left to the shell,
rather than included in each individual program.
paul
__
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> The question is, when nanosec values are available, should they not
> also appear in the terse output from GNU stat? They don't in the
> either the old or the new version:
>
> % /usr/local/bin/stat -t /bin/true
> /bin/true 312 8 81ed 0
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> I notice that the output of stat from coreutils-5.1.2 produces a blank
> line (marked by ---> below) at the end of its report:
>
> 203 eilat::coreutils-5.1.2.p1> /usr/local/bin/stat /bin/true
> File: `/bin/true'
> Size: 312
I notice that the output of stat from coreutils-5.1.2 produces a blank
line (marked by ---> below) at the end of its report:
203 eilat::coreutils-5.1.2.p1> /usr/local/bin/stat /bin/true
File: `/bin/true'
Size: 312 Blocks: 8 IO Block: 65536 regular
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> Also, it would be helpful if GNU date (also part of coreutils) could
> input and output time values since the epoch given on the command
> line, since that would make time conversions easy. I know there is a
> perl module to do that, and GNU gawk c
Dan Jacobson <[EMAIL PROTECTED]> wrote:
> $ info nice does not get one info about nice(1), instead it is some C thing.
Thanks for mentioning that.
The same thing happens for a few others, like rename and stat.
FWIW, as of coreutils-5.1.2, the automatically-generated man pages
refer people to
in
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
...
> with this output on SGI IRIX 6.5:
>
> % ls -l --full-time /bin/true
> -rwxr-xr-x 1 root sys 312 1999-11-04 12:07:38.887783200 -0700 /bin/true
> % stat /bin/true
...
> Change: 1999-11-04 12:07:38.0 -0700
...
> I s
14 matches
Mail list logo
