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

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

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

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: install

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 error

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

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,

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 haven't

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 suggest

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 a

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

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 OP's

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

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

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

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

[patch] shuf.c: Permutation With Replacement

Add support for permutations with replacement: For example: shuf EOF clubs hearts diamonds spades EOF might output: clubs diamonds spades diamonds Please let me know if you would like me to make any changes to the patch. CHANGELOG = shuf.c: Add -w, --with-replacement switches

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

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

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.

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 release tomorrow.