Tim Mooney <[EMAIL PROTECTED]> writes:
> cc: Error: fts.c, line 196: Missing ";". (nosemi)
> return (uintmax_t) ax->ino % table_size;
Thanks for reporting that. Does this patch fix things for you?
2004-01-21 Paul Eggert <[EMAIL PROTECTED]>
* lib/fts.c [! HAVE_INTTYPES_H && HAVE_STD
System: alphaev56-dec-osf5.1 (b)
C Compiler: $cc -V
Compaq C V6.5-207 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-207 (dtk) (dtk) cc Driver
configure for coreutils 5.1.0 correctly detects that uintmax_t can be
found in `stdint.h' (at least as long as you're using the most
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I've begun looking through these and like what I've seen.
>> However, I'd prefer to avoid providing short-named options
>> for --help and --version.
>
> As you like. I did this for compatibility with the Linux /bin/hostname.
> I don't
[EMAIL PROTECTED] (Paul Jarc) writes:
> This is unclear to me. It sounds like what you mean is that the
> *spec* change predates 4.5.1, but the actually-exhibited *behavior*
> change is only a few months old. Is that right?
I meant that the coreutils code itself introduced these changes before
Dan Jacobson <[EMAIL PROTECTED]> writes:
> $ echo|sort +0.3
>
> Emit an error or document +, even as 'old'.
On older systems (which apparently is the kind of system that you're
using), it's not an error.
It is briefly documented in the coreutils manual, under "sort
invocation": look for "obsole
[EMAIL PROTECTED] (Paul Jarc) writes:
> Paul Eggert <[EMAIL PROTECTED]> wrote:
> > + * tests/touch/relative: For 'ls' use TZ=UTC0, not TZ=utc (which isn't
> > + portable).
>
> OOC, is "TZ=UTC" portable?
TZ=UTC is not portable, but TZ=UTC0 has been standardized by POSIX for
many years, and is
>> "command" isn't portable to older shells, so I'm a bit leery about
>> seeing it in portable scripts anyway. ... I suspect that it was a POSIX
>> invention ...
For coreutils, instead of "command ls ...", why not do "$LS ..." where
LS is set at configure time to a full filepath, such as /bin/ls?
Paul Eggert <[EMAIL PROTECTED]> wrote:
> "command" isn't portable to older shells, so I'm a bit leery about
Argh. Thanks for pointing that out.
I *never* intended to put such syntax in a portable script.
I mistakenly copy-pasted it from the command line.
It's gone now.
> seeing it in portable sc
Paul Eggert <[EMAIL PROTECTED]> wrote:
> The 'tail -1' behavior change has been around for a couple of years
> anyway: it predates coreutils 4.5.1, the first version of coreutils
> proper. It didn't become much of an issue, though, until systems
> appeared that claimed conformance to the 2001 POSI
Warren L Dodge <[EMAIL PROTECTED]> writes:
> Another person told me about this to force old behavior.
>
> ./configure CPPFLAGS=-D_POSIX2_VERSION=199209
>
> Should I do this with "all" configures to make sure of what I have?
Better is "./configure DEFAULT_POSIX2_VERSION=199209" as described in
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Perhaps it's because too many people alias "ls" to something else
> using a shell function?
I would have thought aliases would be ignored by a script anyway.
> If so, perhaps the simplest workaround is to replace "command ls"
> with "../../src/ls"
"env ls
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
> make[3]: Entering directory
> `/export/staff/computing/beebe/i386/build/coreutils-5.1.1/tests/touch'
> ls: not found
Thanks for reporting this. This bug undoubtedly occurs because that
test script invokes
command ls -og --time-style=+%Y-%m-%dT
$ echo|sort +0.3
Emit an error or document +, even as 'old'.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Paul Eggert <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>
>> This is still not quite right on systems with TAI clocks.
>
> Good point. Also, I notice that only the first part of my previous
> patch was installed; presumably this is a typo? Anyway, here's a
> patch to the la
Paul Eggert <[EMAIL PROTECTED]> wrote:
> + * tests/touch/relative: For 'ls' use TZ=UTC0, not TZ=utc (which isn't
> + portable).
OOC, is "TZ=UTC" portable?
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listi
[EMAIL PROTECTED] (Paul Jarc) writes:
> This is still not quite right on systems with TAI clocks.
Good point. Also, I notice that only the first part of my previous
patch was installed; presumably this is a typo? Anyway, here's a
patch to the latest CVS snapshot that I have.
Index: ChangeLog
=
Jim Meyering wrote:
> I've begun looking through these and like what I've seen.
> However, I'd prefer to avoid providing short-named options
> for --help and --version.
As you like. I did this for compatibility with the Linux /bin/hostname.
I don't know how important these short options are in pra
The coreutils-5.1.1 build on GNU/Linux on PowerPC produces an apparent
infinite loop in this test:
Machinetype:Apple PowerMac G3 (267 MHz);GNU/Linux 2.4.19-4a (Yellow
Dog Linux release 2.3 (Dayton))
Remote gcc version: gcc (GCC) 3.2.2
Remote g++ version: g++ (GCC) 3.2.2
Co
The coreutils-5.1.1 builds on HP/Compaq/DEC OSF/1 5.1 with gcc had a
few failures:
Machinetype:Compaq AlphaServer DS20 Sierra/667 (2 EV67 21264 CPUs, 667
MHz, 1MB RAM); OSF/1 5.1
Remote gcc version: gcc (GCC) 3.3 20030407 (prerelease)
Remote g++ version: g++ (GCC) 3.3 20030407
There were consistent test failures for the coreutils-5.1.1 builds on
Compaq/DEC OSF/1 4.0:
Machinetype:DEC Alpha 4100-5/466 (4 CPUs, 466 MHz, 2GB RAM);
OSF/1 4.0F
Remote cc version: DEC C V5.9-005 on Digital UNIX V4.0 (Rev. 1229)
Package:coreutils-5.1.1
The coreutils-5.1.1 builds on HP/Compaq/DEC OSF/1 5.1 had a few failures:
Machinetype:Compaq AlphaServer DS20 Sierra/667 (2 EV67 21264 CPUs, 667
MHz, 1MB RAM); OSF/1 5.1
Remote c89 version: Compaq C V6.3-028 on Compaq Tru64 UNIX V5.1 (Rev. 732)
Configure environment: CC=c89 CXX=c
Paolo Montrasio <[EMAIL PROTECTED]> writes:
> Failure 1)
> When a new file is created the nanosecond component of the timestamp
> cannot be set by cp. This is a quote from cp's code:
>
> Failure 2)
> The filesystem might not have a nanosecond time resolution, so we
> have to properly identify th
Warren L Dodge <[EMAIL PROTECTED]> writes:
> On the two solaris systems the following command works.
> tail -1 file
> On linux is complains and says to use
> tail -n 1 file
> Any idea what caused this?
It's because your GNU/Linux systems have that claim
conformance to POSIX 1003.1-2001, wher
There were 2 test failures for the coreutils-5.1.1 build on Apple MacOS X
that terminated the tests:
Machinetype:Apple PowerMac G4 (2 1400 MHz PowerPC 7450 CPUs, 2GB RAM);
Darwin 6.5 (MacOS 10.2.5)
Package:coreutils-5.1.1
Remote cc version: cc (GCC) 3.3 20030304
The coreutils-5.1.1 build on FreeBSD 4.4 on Intel IA-32 reported a single test failure:
Machinetype:Intel Pentium II (2 CPUs, 450 MHz); FreeBSD 4.4.0
Package:coreutils-5.1.1
Remote uname: FreeBSD ee.ece.utah.edu 4.4-RELEASE FreeBSD 4.4-RELEASE #0:
Tue O
Paul Eggert <[EMAIL PROTECTED]> wrote:
> 2004-01-19 Paul Eggert <[EMAIL PROTECTED]>
>
> * tests/touch/relative: Use TZ=UTC0, not TZ=utc (which isn't
> portable). Problem reported by Christian Krackowizer. Also, use
> + rather than +0 to specify a time zone, as the document
> That means that you want me to do the work, I guess? OK, here's the program,
> consisting of
> - a patch to lib/gethostname.c to add Woe32 support,
> - a new src/hostname.c,
> - some autoconf macros that you can add to configure.ac or where it fits.
Thank you.
I've begun looking through th
Warren L Dodge wrote:
> I built coreutils-5.0 on solaris 2.51, solaris 8, and linux
Nice! So now you have the same utilities available on all three of
those types of systems.
> On the two solaris systems the following command works.
> tail -1 file
You mean on solaris using which set of utilitie
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
>I don't understand why should hostname move into inetutils.
>
> Because it is a "internet" tool.
Well, it has sort of become one. But Unix has had hostname longer
than it has had networks, IIRC, and hostname does not do any network
communication
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
> You could set _POSIX2_VERSION on the GNU/Linux system to 199209. From
> (coreutils)Standards conformance
...
> The GNU utilities normally conform to the version of POSIX that is
> standard for your system. To cause them to conform to a differen
As we work in a multi-platform environment it is important to
remain compatible with the Solaris utilities.
You could set _POSIX2_VERSION on the GNU/Linux system to 199209. From
(coreutils)Standards conformance
In a few cases, the GNU utilities' default behavior is
incompatible with t
I just had a look into
http://www.tazenda.demon.co.uk/phil/net-tools/ and they are GNU
version 2 licensed.
You mean "GNU General Public License version 2", and what the license
is, is irrelevant to the discussion.
> Debian GNU/Hurd uses net-tools I belive, but this conflicts with
>
On Fri, 16 Jan 2004 09:13:01 +0100, Jim Meyering wrote:
> I realized that, contrary to our patches, these proposed changes should
> be independent of `preserve_timestamps'.
Jim,
you're right. However there is more to this problem than that because we have to deal
with two different causes of fai
I built coreutils-5.0 on solaris 2.51, solaris 8, and linux
On the two solaris systems the following command works.
tail -1 file
On linux is complains and says to use
tail -n 1 file
"head" has the same issue.
Any idea what caused this?
As we work in a multi-platform environment it is impor
On Sat, 10 Jan 2004, Alfred M. Szmidt wrote:
>Do any of you know if there is a `hostname' program that is
>featureful and portable enough that we could simply remove hostname
>from coreutils -- or at least stop installing it?
>
> I would strongly object to the removal of `hostname' in
hi, im running debian woody and i did this:
localhost:/mnt# cat /dev/sg0
Segmentation fault
then cat segfaulted. i played with it and could not
get it to reproduce itself except one time. at the
time i was messing with ide-scsi in the kernel (2.6.1)
i did however manage to run an strace as th
36 matches
Mail list logo