[bug #22065] add uniq options: --check-fields and --separator

2008-01-20 Thread anonymous

URL:
  

 Summary: add uniq options: --check-fields and --separator
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Sunday 01/20/2008 at 19:53 UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

there was systems supporting --check-fields and --separator
options of the uniq command,  these options are very useful

A patch adding the options is at:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg00128.html





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: PDT timezone bug in GNU coreutils "date" v6.9

2008-01-20 Thread Paul Eggert
Philip Rowlands <[EMAIL PROTECTED]> writes:

> However, in the context of getdate's grammar, "EST" unambiguously
> means -0500, no?

No.  Not necessarily.  It depends on your TZ setting.  It might
reasonably mean +1000, for example.  One cannot rely on "EST" meaning
-0500.  Nor can one rely on "PDT" meaning -0700; that can also be
overridden by a TZ setting.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Command line parsing of ls with genparse: inline code

2008-01-20 Thread Jim Meyering
[EMAIL PROTECTED] (Michael Geng) wrote:
> when I posted a patch around Christmas which showed how genparse
> could generate the parser code for the ping command of the inetutils
> Alfred Szmidt replied that in that example there are 2 loops (see
> http://lists.gnu.org/archive/html/bug-inetutils/2007-12/msg7.html):

Hi Michael,

Thanks for all the good work.
I'll take a look after coreutils-6.10.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: new snapshot [Re: coreutils 6.9.92 fail to configure on *bsd

2008-01-20 Thread Jim Meyering
Elias Pipping <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 17, 2008 at 03:34:20PM +0100, Jim Meyering wrote:
>> I've built a new snapshot:
>>
>>   http://meyering.net/cu/coreutils-ss.tar.gz
>>   http://meyering.net/cu/coreutils-ss.tar.lzma
>>   http://meyering.net/cu/coreutils-ss.tar.gz.sig
>>   http://meyering.net/cu/coreutils-ss.tar.lzma.sig
>>
>> and confirmed that it fixes all of those problems on your
>> i386-apple-darwin9.1.0 system, as long as you disable ACL support:
>>
>> ./configure --disable-acl
>>
>> The other two failures were fixed via changes in gnulib:
>>
>> > FAIL: test-frexpl
>> > FAIL: test-printf-frexpl
>
> With the above snapshot and --disable-acl, all of the default tests,
> including those enabled via RUN_VERY_EXPENSIVE_TESTS pass.

Thanks for testing it.

> as for the check-root tests:
>
>   this one now passes:
>
> special-bits
>
>   these fail:
>
> rm/fail-2eperm
> cp/preserve-gid
> touch/now-owned-by-other

It looks like they're all due to the fact that you used
NON_ROOT_USERNAME=nobody and "nobody" lacks access to required
files.  Can you run it again, as recommended in README
i.e., using NON_ROOT_USERNAME=your_user_name (assuming the
source tree belongs to "your_user_name"):

**
Running tests as root:
--

If you run the tests as root, note that a few of them create files
and/or run programs as a non-root user, `nobody' by default.
If you want to use some other non-root username, specify it via
the NON_ROOT_USERNAME environment variable.  Depending on the
permissions with which the working directories have been created,
using `nobody' may fail, because that user won't have the required
read and write access to the build and test directories.
I find that it is best to unpack and build as a non-privileged
user, and then to run the following command as that user in order
to run the privilege-requiring tests:

  sudo env NON_ROOT_USERNAME=$USER make -k check-root

If you can run the tests as root, please do so and report any
problems.  We get much less test coverage in that mode, and it's
arguably more important that these tools work well when run by
root than when run by less privileged users.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils