Paul Eggert <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> I think it ought to be possible for the user building coreutils to say
>> what version of conformance they want - say, with a ./configure
>> argument - and this should override the unistd.h definition.
>
> That might
> Good point. The README is a bit obsolete anyway, as it talks about
> "POSIX.2". Here's a proposed patch.
>
> 2003-11-04 Paul Eggert <[EMAIL PROTECTED]>
>
> * README: Document _POSIX2_VERSION.
>
> --- README.~1.12.~Tue Jul 29 13:55:00 2003
> +++ READMETue Nov 4 10:50:42 2003
Th
Dennis Smit <[EMAIL PROTECTED]> wrote:
> I've been playing with valgrind and the gnu coreutils and found that
> some of these utils have small memleaks, i would love to fix them and
> send patches. Are you people intrested in such patches ?
Yes.
Please base any changes on the very latest versions
"Stephan T. Lavavej" <[EMAIL PROTECTED]> wrote:
> configure fails with:
>
> checking for fs_info.h... no
> checking for BEOS mounted file system support functions... no
> checking whether it is possible to resort to fread on /etc/mnttab... no
> configure: error: could not determine how to read list
Dennis Smit <[EMAIL PROTECTED]> wrote:
...
> there is memory allocated within the read_utmp function for
> utmp_buf:
> int fail = read_utmp (filename, &n_users, &utmp_buf);
>
> which is never being freed.
>
> This is solved by the following patch:
> --
> --- users.c 2003-10-30
[EMAIL PROTECTED] (Paul Jarc) writes:
> I think it ought to be possible for the user building coreutils to say
> what version of conformance they want - say, with a ./configure
> argument - and this should override the unistd.h definition.
That might be reasonable. The coreutils maintainer shoul
[EMAIL PROTECTED] writes:
> The attached 1 line patch uses the maximum of the two block sizes and
> fixes the problem I'm seeing.
Surely it should use the least common multiple of the two block sizes?
(Checking for overflow, of course.)
___
Bug-coreu
Hello,
I've ran into an issue with using the 'cp' tool. In short, I was
wondering why the optimal buffer size (as noted in comments) for a
copy is the destination block size (as reported by fstat) instead of
the maximum of the source and destination block sizes.
Imagine the following scenario:
Paul Eggert <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> If the choice is somehow truly under the control of the coreutils
>> installer, then I would be happier.
>
> It's clearly under their control now.
It's clearly under the control of the libc installer, but what if the
[EMAIL PROTECTED] (Paul Jarc) writes:
> How is that controlled, exactly? I think it ought to be documented in
> README.
Good point. The README is a bit obsolete anyway, as it talks about
"POSIX.2". Here's a proposed patch.
2003-11-04 Paul Eggert <[EMAIL PROTECTED]>
* README: Docume
Paul Eggert <[EMAIL PROTECTED]> wrote:
> It's up to your the coreutils installer (typically a software
> distribution maintainer) to specify the default value for
> _POSIX2_VERSION.
How is that controlled, exactly? I think it ought to be documented in
README.
> So the compatibility problems that
Hello ,
i have the following problem to install
adminmod .58 on my redhat linux 9.0 server . my 1.5 server is upgraded to a 1.6
with steam .
this is the error output i see on the screen
:
Installing Metamod binaries to cstrike/addons/metamod... done.
Updating your liblist.game file... do
Hi there,
As "install" can take care of the code in an installed files, by
stripping it, it could take care of the symlinks when installing
them.
For now, "install" copies the symlinks as "cp" does, so the target
directory will contain one copy of the target file per symlink.
Provided that the li
David Daney <[EMAIL PROTECTED]> wrote:
> $ mipsel-linux-gcc --version
> mipsel-linux-gcc (GCC) 3.3.1
...
> $ ../coreutils-5.0/configure --build=i686-linux --host=mipsel-linux
> --target=mipsel-linux
>
> Results in the following lines in config.h:
...
> #define UTILS_OPEN_MAX cross compiling run-tes
ari <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] said this stuff:
>
> > After 10 years of being merely `obsolescent', head -N has finally
> > been officially declared to be `obsolete'.
>
> I have yet to see a pointer to where the historic usage has been
> declared "obsolete", outside of perso
[EMAIL PROTECTED] said this stuff:
> After 10 years of being merely `obsolescent', head -N has finally
> been officially declared to be `obsolete'.
I have yet to see a pointer to where the historic usage has been
declared "obsolete", outside of personal declarations that it has been
"officially d
16 matches
Mail list logo
