Re: Could we have a flag to tell us which directories were actually removed?

Reuben Thomas <[EMAIL PROTECTED]> wrote: > On Wed, 15 Aug 2007, Jim Meyering wrote: > >> Reuben Thomas <[EMAIL PROTECTED]> wrote: >>> I just had a situation where this would have been useful. I tried -v >>> --ignore-fail-on-non-empty, but of course it told me about every >>> directory it processed,

Re: 'futimens' name conflict with glibc-2.6.1 header file sys/stat.h

On Thursday 16 August 2007, سید حسن فیروزآبادی wrote: > Thanx Mike, but since I dont like using cvs codes so tried to fix the > release be doing this: > > sed -i "[EMAIL PROTECTED]@hassan_&@" $(echo `find . -type f -print | xargs > grep > -li 'futimens'`) > > and the code compiled successfully. do

Re: 'futimens' name conflict with glibc-2.6.1 header file sys/stat.h

Thanx Mike, but since I dont like using cvs codes so tried to fix the release be doing this: sed -i "[EMAIL PROTECTED]@hassan_&@" $(echo `find . -type f -print | xargs grep -li 'futimens'`) and the code compiled successfully. do u think that is gonna cause problems? On 8/16/07, Mike Frysinger

Re: 'futimens' name conflict with glibc-2.6.1 header file sys/stat.h

On Wednesday 15 August 2007, Bob Proulx wrote: > > internal 'futimens' name has conflict with glibc-2.6.1 header file > > sys/stat.h > > a patch would be wonderful > > Can you post the error message that you are seeing back to the mailing > list? That would help us know what is happening. this ha

Re: Could we have a flag to tell us which directories were actually removed?

Reuben Thomas wrote: > I wanted this for keyboard use, for multiple directories: > rmdir [--magic-flag] * Let me keep working the problem... How about this? perl -le 'for my $i (@ARGV) { print $i if rmdir($i); };' * That would be quite easy to turn into a script to reuse more often such as

Re: mv can't change filename case on case-insensitive file systems

> > FAT is always upper case and the driver forces it to > lower case. VFAT ignores attempts to change case > with rename(), in conformity to Posix. You missed my earlier remark - since POSIX requires case sensitivity, a case-insensitive file system is not specified by POSIX, therefore, a platfo

Re: Could we have a flag to tell us which directories were actually removed?

On Wed, 15 Aug 2007, Jim Meyering wrote: Reuben Thomas <[EMAIL PROTECTED]> wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. Why add a new o

Re: Could we have a flag to tell us which directories were actually removed?

On Wed, 15 Aug 2007, Bob Proulx wrote: Reuben Thomas wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. How about this? $ mkdir -p 1/2/3 11

Re: mv can't change filename case on case-insensitive file systems

On Wednesday, August 15 2007, "Eric Blake" wrote to "Jonathan Lennox, bug-coreutils@gnu.org" saying: > > (I reported this issue on the bug tracker on Savannah, but it looks like > > sending bug reports to this mailing list is preferred, so I'm repeating it > > here.) > > The bug-tracker forwards

Re: DWIM feature request for cp

2007/8/15, Bob Proulx <[EMAIL PROTECTED]>: > If you are using GNU bash then it is pretty easy to avoid .. if you > want. > > echo cp -r .!(.|) target/ OK, thank you all for your explanations. I wasn't aware of the expansion in shell. I'll read more about that in the Bash manpage. -- Roberto R

Re: DWIM feature request for cp

Alfred M. Szmidt scripsit: >Hello, I want to ask the developers what do they think about >implementing a way to do "cp -r .* target" (copy files and >directories starting with dot) without copying the parent directory >".." (I think that's what the user usually intends to do) > >

Re: Could we have a flag to tell us which directories were actually removed?

Reuben Thomas wrote: > I just had a situation where this would have been useful. I tried -v > --ignore-fail-on-non-empty, but of course it told me about every directory > it processed, which is fine, but not what I wanted. How about this? $ mkdir -p 1/2/3 11 $ rmdir -v 1 rmdir: removing d

Re: DWIM feature request for cp

On Wed, Aug 15, 2007 at 04:01:52PM -0300, Roberto Rodr?guez wrote: > Hello, I want to ask the developers what do they think about implementing a > way to do "cp -r .* target" (copy files and directories starting with dot) > without copying the parent directory ".." (I think that's what the user > u

Re: DWIM feature request for cp

Roberto Rodríguez wrote: > Hello, I want to ask the developers what do they think about implementing a > way to do "cp -r .* target" (copy files and directories starting with dot) > without copying the parent directory ".." (I think that's what the user > usually intends to do) The first thing to

Re: Command touch and irregular file names

On Tue, 14 Aug 2007, - Tong - wrote: How to let command touch to work with irregular file names? FYI, I tried this but didn't work: $ touch -r -- "-test.file1" "-test.file2" touch: invalid date format `est.file1' That's nearly right; put the -- immediately following the last option, e.g.

Re: DWIM feature request for cp

Hello, I want to ask the developers what do they think about implementing a way to do "cp -r .* target" (copy files and directories starting with dot) without copying the parent directory ".." (I think that's what the user usually intends to do) Won't work, globs is expanded by the she

Re: Could we have a flag to tell us which directories were actually removed?

Reuben Thomas <[EMAIL PROTECTED]> wrote: > I just had a situation where this would have been useful. I tried -v > --ignore-fail-on-non-empty, but of course it told me about every > directory it processed, which is fine, but not what I wanted. Why add a new option? While adding a new rmdir option

Re: 'futimens' name conflict with glibc-2.6.1 header file sys/stat.h

سید حسن فیروزآبادی wrote: > internal 'futimens' name has conflict with glibc-2.6.1 header file > sys/stat.h > a patch would be wonderful Can you post the error message that you are seeing back to the mailing list? That would help us know what is happening. Thanks Bob __

DWIM feature request for cp

Hello, I want to ask the developers what do they think about implementing a way to do "cp -r .* target" (copy files and directories starting with dot) without copying the parent directory ".." (I think that's what the user usually intends to do) Thank you all and keep the good work, Roberto -- R

RE: coreutils rm - win32 native port

On Wed, 15 Aug 2007, Aviad Lahav wrote: I'm sorry but this is getting much too religious debate, Maintaining multi-platform utilities on which users of many of those platforms depend minute-by-minute is a tricky enterprise. I don't see any "religious debate" here, only a platform-specific ve

'futimens' name conflict with glibc-2.6.1 header file sys/stat.h

Hi internal 'futimens' name has conflict with glibc-2.6.1 header file sys/stat.h a patch would be wonderful Regards ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Could we have a flag to tell us which directories were actually removed?

I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. -- http://rrt.sc3d.org/ | violence, n. bravery for cowards _

Re: mv can't change filename case on case-insensitive file systems

Eric Blake scripsit: > Consider - should > rename("Foo", "foo") be a no-op when stat("Foo") and stat("foo") > resolve to the same file? Reading just the POSIX rename(2) > requirements seems to say yes (it requires rename to be a no-op > when both names resolve to the same inode, ie. no case chang

Re: ar(1) issue building coreutils on 64-bit AIX

On Tue, 2007 Aug 14 08:47:07 +0200, Jim Meyering wrote: > > > > AR_FLAGS="-X64 cru" > > coreutils doesn't use libtool, but it does use automake. > And automake uses the "ARFLAGS" spelling. I lament the inconsistency, but that's a fair point. > No need to edit Makefiles. > Just invoke make wi

RE: coreutils rm - win32 native port

I'm sorry but this is getting much too religious debate, and I don't really have the time to spend on it. If you want the updates, I'll post them (along with additional changes to support mv & cp). If not, it's a pity - I think you're turning against your users. > -Original Message- > F

RE: coreutils rm - win32 native port

> > Only because someone volunteers to maintain it. > > So, if I volunteer to maintain win32 support, would coreutils accept the > changes? If your changes are not deemed too invasive (you haven't even posted them yet), and if you have copyright assignment, then perhaps Jim will be willing to let

RE: coreutils rm - win32 native port

> The reality is quite the opposite of what you've said: have you looked in > remove.c ? It's full of sun's proprietary functions: openat() and similar; Those aren't Sun proprietary. They are being added by the next revision of POSIX, and have already been adopted by Linux. Cygwin is not far fro

RE: coreutils rm - win32 native port

First Bob, then Eric :) > http://www.gnu.org/prep/standards/html_node/System-Portability.html#System-P ortability This policy explains why not initiate non-gnu-os porting (for which I have a good answer: I need it) - but not why to *reject* them. >remove.c was almost completely re-written

Re: Bug in od with "-j" option?

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> + If the number of bytes left to skip is larger than >> + the size of the current file, we can decrement >> + n_skip and go on to the next file. */ >>if (S_ISREG (file_stats.st_m

Obsolete fileutils, shellutils, textutils web pages updated

Just an fyi... I have updated the web pages for the obsolete fileutils, shellutils, textutils to remove obsolete information leaving only the redirect to the new coreutils and also updated them to the new gnu.org html page templates. As Paul said when he updated the main coreutils page a while ba

Re: Broken link

Shugart, Ashley J ERD-GSL-MS wrote: > http://www.gnu.org/software/coreutils/ says: > > Coreutils can be found on ... one of our FTP mirrors > . > > But the link to the mirrors is broken. Thank you for reporting that problem. The location of the mirrors page seems

Re: coreutils-6.9 problem with --preserve-timestamps

Warren L Dodge wrote: > I just found an issue where coreutils-6.9 does not seem to work right with > the --preserve=timestamps switch when copying to an nfs filesytem when the > pwd is the same directory. Thanks for the report. Could you run your test case again under 'strace' and report the resu

Re: printf --help

[EMAIL PROTECTED] (Karl Berry) wrote: > The --help message for printf (coreutils 6.9) starts with this: > > Usage: /usr/local/gnu/bin/printf FORMAT [ARGUMENT]... > or: /usr/local/gnu/bin/printf OPTION > Print ARGUMENT(s) according to FORMAT. > > --help display this help

Re: Command touch and irregular file names

- Tong - wrote: > In my script I have > > touch -r "$file1" "$file2" > > the file1/2 can be anything file, ../path/file, /root/file, etc. > > The problem is when file1/2 are irregular file names. E.g., -test.file1/2. > > I.e., anyway to make the following touch command works? > > $ touch -r

Command touch and irregular file names

Hi, How to let command touch to work with irregular file names? In my script I have touch -r "$file1" "$file2" the file1/2 can be anything file, ../path/file, /root/file, etc. The problem is when file1/2 are irregular file names. E.g., -test.file1/2. I.e., anyway to make the following touc

Broken link

http://www.gnu.org/software/coreutils/ says: Coreutils can be found on ... one of our FTP mirrors . But the link to the mirrors is broken. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/l

coreutils-6.9 problem with --preserve-timestamps

I just found an issue where coreutils-6.9 does not seem to work right with the --preserve=timestamps switch when copying to an nfs filesytem when the pwd is the same directory. I had a copy of the coreutils-5.0 available and it worked fine. cd /some/nfs/mounted/directory ll file -rw-rw-r-- 1 w