Re: one last snapshot before test release

Matthew Woehlke <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I've made another snapshot: >> http://meyering.net/cu/coreutils-6.7-dirty.tar.gz >> http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig >> Please give it a try and report anything strange. >> I expect to make a test relea

minor change to silence Sun C 5.8 warning on Solaris 10

Here's the patch. I don't normally like unnecessary casts, but I guess for static initializers we can make an exception 2007-02-20 Paul Eggert <[EMAIL PROTECTED]> * src/copy.c (cached_umask): Cast -1 to mode_t to avoid a warning about out-of-range initializer with Sun C 5.8

minor gnulib fixups to help port latest coreutils to Solaris 10

I installed this to work around some porting problems on Solaris 10. dirfd needs declaring. And cc complains about rpl_putenv being redeclared with a different type, since Solaris 10 header files declare it with a char * arg. 2007-02-20 Paul Eggert <[EMAIL PROTECTED]> Minor fixups to p

Re: one last snapshot before test release

Jim Meyering wrote: I've made another snapshot: http://meyering.net/cu/coreutils-6.7-dirty.tar.gz http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig Please give it a try and report anything strange. I expect to make a test release tomorrow. 'make && make check' is clean on AIX 5.1

[patch] shuf.c: Permutation With Replacement

Add support for permutations with replacement: For example: shuf

Re: install.c: please set unlink_dest_before_opening=false

"Robert Millan [ackstorm]" <[EMAIL PROTECTED]> writes: > I haven't checked POSIX though, but if this is actualy a requirement > maybe a POSIX_ME_HARDER hack would make sense here? POSIX makes no requirement. Other implementations are all over the map here, so I suppose we can do what is more con

one last snapshot before test release

I've made another snapshot: http://meyering.net/cu/coreutils-6.7-dirty.tar.gz http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig Please give it a try and report anything strange. I expect to make a test release tomorrow. ___ Bug-coreutils m

Re: Sort

<[EMAIL PROTECTED]> writes: > 104 4 > 105 > > But it doesn't work. Sounds like you wanted "sort -n" rather than plain "sort". Plain "sort" operates lexicographically. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mail

Re: Sort

[EMAIL PROTECTED] wrote: I tried to sort a small file containing the following 2 rows using "cat x | sort" 104 4 105 But it doesn't work. That's not a very helpful bug report. What do you get? What did you expect to get? And did you check your locale settings? ('man sort' talks about t

Sort

Hi, I tried to sort a small file containing the following 2 rows using "cat x | sort" 104 4 105 But it doesn't work. My current linux version is: 2.6.9-34.Elsmp BR, -- Mehran ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu

Re: new coreutils snapshot; are they useful?

Jim Meyering wrote: Matthew Woehlke wrote: might be useful to have some way to run the test suite in a different directory, so that it is easy to run once on NFS and once on local. In particular I remember that on Darwin this was important. To build and run "make check" using various writable

Re: env

Harvey Eneman <[EMAIL PROTECTED]> wrote: > I've experienced an issue with the env implementation due to its > modification of the environ external variable: > > /* If no program is specified, print the environment and exit. */ > if (argc <= optind) >{ > while (*environ) > puts (*

Re: env

> As env exits immediately, I'm having difficulty seeing what problems > you're encountering. > > > The difficulty occurs when a LD_PRELOAD shared object uses glib > > functions that rely in the stability of environ. > > No function is called before exit(EXIT_SUCCESS). Not true. I can see the

Re: env

On Mon, 19 Feb 2007, Harvey Eneman wrote: I've experienced an issue with the env implementation due to its modification of the environ external variable: /* If no program is specified, print the environment and exit. */ if (argc <= optind) { while (*environ) puts (*environ++)

Re: cp should look for destination file operand BEFORE wildcard expansion

[EMAIL PROTECTED] (Eric Blake) writes: > However, you can use other shell features, such as aliases > or shell functions, to enable other features of cp by default > when invoking cp in an interactive manner. For example, > this is a pretty common idiom: > > $ alias cp='cp -i' Don't do that, use

Re: cp should look for destination file operand BEFORE wildcard expansion

Anshul Nigham wrote: > Hi > > Using wildcard expansion, it is possible to unintentionally overwrite > files. E.g. consider a directory with two text files, a.txt and b.txt. > > $ cp *.txt > $ cat b.txt > I am A!! > > I don't think this could be intended or expected behavior in any > scenario. I

Re: install.c: please set unlink_dest_before_opening=false

> install --help says it will just "copy SOURCE to DEST", so one would > expect to behave like cp and not break hard links. > > However, because unlink_dest_before_opening is set to true, this will > break links. Thanks for the report. How do non-GNU install programs behave in this regard? > I

Re: Bug or Feature in join?

> I admit I haven't searched the bug database, just came across the > following problem with join version 5.97. Consider upgrading - the latest stable version is 6.7 (although for the case you mention, I don't think it will help much). > > Two files, A and B. B contains all numbers from 1 to, e

Re: cp should look for destination file operand BEFORE wildcard expansion

> Using wildcard expansion, it is possible to unintentionally overwrite > files. E.g. consider a directory with two text files, a.txt and b.txt. Thanks for the report. However, this is not cp's problem. Look at the output of $ echo cp *.txt to learn what cp actually sees, and you will notice t

Re: cp should look for destination file operand BEFORE wildcardexpansion

Anshul Nigham wrote: > I don't think this could be intended or expected behavior in any > scenario. I suggest that the cp behavior be modified to look for a > destination file operand before expanding wildcards, in which case a > command like "cp [options] wildcard-expr" would still exit with an >

install.c: please set unlink_dest_before_opening=false

Hi, install --help says it will just "copy SOURCE to DEST", so one would expect to behave like cp and not break hard links. However, because unlink_dest_before_opening is set to true, this will break links. Unless you notice about this, it's quite a problem when you do something like: instal

Bug or Feature in join?

Hello, I admit I haven't searched the bug database, just came across the following problem with join version 5.97. Two files, A and B. B contains all numbers from 1 to, e.g., 12. a) A contains the two lines 1 10 The output of join is _only_ the line "1". b) A contains the

cp should look for destination file operand BEFORE wildcard expansion

Hi Using wildcard expansion, it is possible to unintentionally overwrite files. E.g. consider a directory with two text files, a.txt and b.txt. $ ls a.txt b.txt $ cat a.txt I am A!! $ cat b.txt I am B!! $ cp a.txt cp: missing destination file operand after `a.txt' Try `cp --help' for more infor

env

I've experienced an issue with the env implementation due to its modification of the environ external variable: /* If no program is specified, print the environment and exit. */ if (argc <= optind) { while (*environ) puts (*environ++); exit (EXIT_SUCCESS); } The diffic