Bruno Haible <[EMAIL PROTECTED]> writes:
> Suggestion: Could shred, when encountering this error on a block device file,
> print the error message but nevertheless continue with the remaining passes?
> That would be more useful than the current behaviour.
'shred' already attempts to do just that
Bruno Haible <[EMAIL PROTECTED]> writes:
> The 'df' program needs a small adjustment so that the 'struct statvfs' of
> BeOS can be used. And the 'stat' program needs porting too; here the
> 'struct statvfs' cannot be used, because it does not have a f_type
Thanks. While testing this on GNU/Linux
I installed this. I suppose it could be autoconfed, but it'd be a
runtime test
2006-08-23 Paul Eggert <[EMAIL PROTECTED]>
* NEWS: printf supports the I flag.
* src/printf.c (print_formatted) [glibc 2.2 or later]: Likewise.
--- NEWS23 Aug 2006 09:17:14 - 1.
On Wednesday 23 August 2006 17:56, Matthew Burgess wrote:
> http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-unam
>e-1.patch changes the output of `uname -i' and `uname -p' from 'unknown' to
> the correct platform and processor respectively on x86 machines running
> Linux. I
Matthew Burgess <[EMAIL PROTECTED]> writes:
> http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-uname-1.patch
> What would be the preferred method of seeing the -i and -p flags of
> uname produce correct output on x86-linux machines? I'm assuming it
> needs either kernel or g
Hi folks.
Firstly, the good news :-) The new experimental 6.1 release builds and
completes the testsuite fine on a recent Linux system (linux-2.6.17.8,
gcc-4.1.1, glibc-2.3.6).
Now for the nitty gritty!
There are instructions for building Coreutils at
http://www.linuxfromscratch.org/lfs/vi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The fact that you wrote to the obsolete bug-textutils address implies that
you are probably due for an upgrade; perhaps using a newer version of
coreutils will solve the problem for you. The latest stable version is
5.97, or you can try the experiment
Hello Support,
When I run tail.exe -f in a command window it causes the PC speaker
to beep non-stop until the window is closed.
Is there any way to stop this?
Russell Mattson
Oracle DBA
___
Bug-coreutils mailing list
Bug-coreutils@gnu.o
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-19 Bruno Haible <[EMAIL PROTECTED]>
>
> BeOS portability.
> * src/ls.c (SA_RESTART): Fallback define.
Thanks, I installed that.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http:
Bruno Haible <[EMAIL PROTECTED]> writes:
> BeOS has no quotas and no EDQUOT. Fortunately it is easy to fix.
Thanks. I installed the following slightly-different fix, since we
tend to put those defns in system.h.
2006-08-23 Paul Eggert <[EMAIL PROTECTED]>
* src/system.h (EDQUOT): Defi
This is a bug in your GNU/Linux system, you should report it to the
people who maintain it.
The behaviour you see probobly happens because your shell initialision
file doesn't do:
eval "`dircolors /etc/DIR_COLORS`"
or similar.
Happy hacking.
___
Bu
It's a small thing, but the "gcc ..." lines are getting pretty long
when you build coreutils so I thought I'd shrink them a bit. For
starters I installed this to remove the "-I.. ":
2006-08-23 Paul Eggert <[EMAIL PROTECTED]>
* .cvsignore: Remove config.h, config.hin, as they are now
Hello,
I should probably have reported this earlier. Somewhere in the
transition from Redhat 7.2 to the current Fedora Core 3, a bug cropped
up that I found a work-around for and thus ignored until switching to a
new computer (and home directory):
On a default install, using Gnome's gnome-termi
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-23 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/lock.m4 (gl_LOCK_EARLY): Renamed from gl_LOCK.
Thanks for the heads-up. I installed the patch below to coreutils to
accommodate this.
This leads to one of the issues I had when converting core
Btw, the "#ifdef __GLIBC__" in m4/fsusage.m4 looks wrong also for
the Hurd, because glibc/sysdeps/mach/hurd/statfs64.c does not
appear to access /proc.
/proc doesn't exist on GNU, never did.
Cheers.
___
Bug-coreutils mailing list
Bug-coreutil
The 'df' program needs a small adjustment so that the 'struct statvfs' of
BeOS can be used. And the 'stat' program needs porting too; here the
'struct statvfs' cannot be used, because it does not have a f_type
or f_fstypename or similar field.
Btw, the "#ifdef __GLIBC__" in m4/fsusage.m4 looks wro
On BeOS, compilation fails like this:
source='ls.c' object='ls.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib -Wall
-I/boot/home/config/include -g -O2 -c ls.c
/boot/home/gnubuild/coreutils-6.0/src/ls.c: In func
On BeOS, compilation fails like this:
source='ln.c' object='ln.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib -Wall
-I/boot/home/config/include -g -O2 -c ln.c
/boot/home/gnubuild/coreutils-6.0/src/ln.c: In func
Egmont Koblinger wrote:
> > + @smallexample
> > + printf (ngettext ("One file removed", "%d files removed", n), n);
> > + @end smallexample
>
> Please don't do so, please don't mention this in the manual!...
>
> - "One file", "2 files", "3 files" is really inconsistent and really ugly.
Users vie
On Thu, Aug 17, 2006 at 08:01:54PM +0200, Bruno Haible wrote:
Hi,
> + In the English singular case, the number -- always 1 -- can be replaced with
> + "one":
> +
> + @smallexample
> + printf (ngettext ("One file removed", "%d files removed", n), n);
> + @end smallexample
Please don't do so, ple
Bruno Haible <[EMAIL PROTECTED]> writes:
> The reason is that BeOS does not have PF_INET, only AF_INET, but usually they
> have the same values. Also it doesn't have PF_UNSPEC.
Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find
PF_INET or PF_UNSPEC? Maybe they are in some non-
21 matches
Mail list logo
