On 11/21/2013 12:03 AM, Bernhard Voelker wrote:
if (dot_or_dotdot (last_component (ent-fts_accpath)))
{
- error (0, 0, _(cannot remove directory: %s),
- quote (ent-fts_path));
+ error (0, 0,
+
On 11/21/2013 07:12 AM, Bernhard Voelker wrote:
On 11/21/2013 03:07 AM, Eric Blake wrote:
On 11/20/2013 05:03 PM, Bernhard Voelker wrote:
What about the following?
$ src/rm -r src/.
src/rm: refusing to remove '.' or '..' directory: skipping 'src/.'
That helps.
Thanks, I'll push it
On 20/11/2013 22:32, Bernhard Voelker wrote:
On 11/21/2013 01:48 AM, Linda Walsh wrote:
Isn't it my computer? How do I override such a refusal?
$ rm -rv $(pwd -P)
removed directory: ‘/tmp/xx’
--
That doesn't give the same behavior and isn't what I want.
Compare to cp.
Say I want
On 11/21/2013 10:38 AM, Eric Blake wrote:
On 11/21/2013 10:35 AM, Pádraig Brady wrote:
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing constructs.
Even more generally find(1) could be
On 11/21/2013 10:18 AM, Bob Proulx wrote:
Instead, she wants a command that will recursively remove the
children of ., but then leave . itself unremoved (whether by
virtue of the fact that rmdir(.) must fail
I am missing this part. Why must it fail? And in fact as per my test
case above
On 11/21/2013 01:39 PM, Eric Blake wrote:
On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
Admittedly, compared to the academic question behind --no-preserve-root
(which is like what happens to me when the globe under my feet
disappears?),
there may be more real-world reasons to remove ..
On 11/21/2013 09:41 AM, Tormen wrote:
But I want the same effect than
chown me: /tmp/bla
Ooh, you're right. We DO document that:
I started wondering if I missed something extremely obvious here ;)
No, rather _I_ missed that 'chown --help' is (intentionally) not as
comprehensive as 'info
On 21/11/2013 09:50, Bob Proulx wrote:
Eric Blake wrote:
P�draig Brady wrote:
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing constructs.
Even more generally find(1) could be used to
On Wed, Nov 20, 2013 at 4:03 PM, Bernhard Voelker
m...@bernhard-voelker.de wrote:
On 11/20/2013 02:44 PM, Eric Blake wrote:
On 11/19/2013 11:45 PM, Bernhard Voelker wrote:
Maybe cannot remove directory is a bit weak - it's more like
refusing to remove dot|dot-dot|root directory.
Indeed, a
Eric Blake ebl...@redhat.com writes:
so it looks like we have a bug that if OWNER is numeric, we aren't
looking up OWNER's login group.
There may not be a unique uid to user name mapping.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
On 11/21/2013 09:18 AM, Bernhard Voelker wrote:
On 11/21/2013 04:06 PM, Eric Blake wrote:
Hard to say that it is considerable bloat without seeing a patch; we
already know when the top-level arguments are directories thanks to
'rm -d'.
Here's a draft - not tested more than this:
+++
Dear Gnu Team,
First off: Thanks for existing!! :)))
I think I just found a bug in chown... \o/ ;)
Details about my GNU/Linux system:
Debian wheezy stable 7.2
dpkg -S /bin/chown
coreutils: /bin/chown
dpkg -l|grep coreutils
ii coreutils 8.13-3.5
On 11/21/2013 07:42 AM, Bernhard Voelker wrote:
I'm not happy with the semantic as the difference to all other existing
uses of rm(1) would be that the argument is explicitly not removed,
but well, ...
Such is life - and that's why it requires a new long option.
Such --children-only would
On 11/21/2013 08:53 AM, Eric Blake wrote:
If you provide a colon, you MUST also provide a group spec. Per 'chown
--help', the syntax is:
chown [OPTION]... [OWNER][:[GROUP]] FILE...
Hmm, on re-reading this, I think we have two bugs in our help syntax.
The major bug is that we document [GROUP]
On 11/21/2013 10:45 AM, Andreas Schwab wrote:
Eric Blake ebl...@redhat.com writes:
so it looks like we have a bug that if OWNER is numeric, we aren't
looking up OWNER's login group.
There may not be a unique uid to user name mapping.
Right, but in that case, the error message should make
On 11/21/2013 02:39 PM, Eric Blake wrote:
[...] Instead, she wants a command that will
recursively remove the children of ., but then leave . itself
unremoved (whether by virtue of the fact that rmdir(.) must fail and
so the overall rm command fails, or by explicitly skipping the attempt
to
On 11/21/2013 11:07 AM, Tormen wrote:
There may not be a unique uid to user name mapping.
Interesting. But I guess the ID (for owner and group) is what is stored
in the filesystem
(as you can rename users and the ID stays the same on the file).
In which case there is no tranlsation (ID -
Thanks a lot for explaining!!
On 21/11/13 21:53, Eric Blake wrote:
Right, but in that case, the error message should make sense. Rather
than being a blanket invalid spec: `1001:' it should say something
like unable to determine default group for user `1001'
So in no case there should be a
Eric Blake wrote:
Pádraig Brady wrote:
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing constructs.
Even more generally find(1) could be used to handle arbitrarily
many files and
Dear GNU team,
But why is not possible for chown 1001: /tmp/bla
to resolve 1001 to me
and then do the same than chown me: /tmp/bla ?
(I guess internally chown will do the reverse lookup (me - 1001), when
performing a chown me: /tmp/bla)
Could you please be so kind to explain the why not ?
Hi again,
Sorry, I don't know why, but I missed this part of your answer:
On 21/11/13 16:53, Eric Blake wrote:
I think I just found a bug in chown... \o/ ;)
I tried:
chown 1001: /tmp/bla
Leading to:
chown: invalid spec: `1001:'
Drop the trailing colon.
But I want the same
On 21/11/2013 09:18, Bob Proulx wrote:
Eric Blake wrote:
But that's not what Linda is asking for. She is not asking to pull .
out of under her feet.
Actually as I understand it she is expecting the call to succeed if
the system kernel allows it. I believe that is the way rm used to
work
Bob Proulx wrote:
Long ago this was an existing behavior of GNU rm and discussion on the
s/rm/chown/
Argh! The recent 'rm' discussion clouded my typing. I meant 'chown' there.
Bob
Eric Blake wrote:
OWNER':'
If a colon but no group name follows OWNER, that user is made the
owner of the files and the group of the files is changed to OWNER's
login group.
Long ago this was an existing behavior of GNU rm and discussion on the
list talked of removing it. I
tag 15945 - notabug
reopen 15945
thanks
On 11/21/2013 09:24 AM, Tormen wrote:
Leading to:
chown: invalid spec: `1001:'
Drop the trailing colon.
But I want the same effect than
chown me: /tmp/bla
Ooh, you're right. We DO document that:
OWNER':'GROUP
If the OWNER is followed
On 21/11/13 17:44, Eric Blake wrote:
On 11/21/2013 09:41 AM, Tormen wrote:
But I want the same effect than
chown me: /tmp/bla
Ooh, you're right. We DO document that:
I started wondering if I missed something extremely obvious here ;)
No, rather _I_ missed that 'chown --help' is
On Thu, Nov 21, 2013 at 8:18 AM, Bernhard Voelker
m...@bernhard-voelker.de wrote:
On 11/21/2013 04:06 PM, Eric Blake wrote:
Hard to say that it is considerable bloat without seeing a patch; we
already know when the top-level arguments are directories thanks to 'rm
-d'.
Here's a draft - not
On 11/19/2013 05:15 AM, Pádraig Brady wrote:
So how about upgrading 'rm' to use the remove function so
it would work on empty directories as well.
Well we have the -d option to rm to explicitly do that.
That's a fairly fundamental change that would have backwards compat issues.
POSIX is
On 11/21/2013 11:01 AM, Pádraig Brady wrote:
I'm not sure it's useful enough functionality to expose,
and personally I'd use something like:
children() { find $1 -maxdepth 1 -mindepth 1; }
or
children() { find $1 | sed '1d'; }
and then...
children $dir | xargs rm -r
Except that it
On 11/21/2013 09:34 AM, Bernhard Voelker wrote:
On 11/21/2013 05:25 PM, Eric Blake wrote:
On 11/21/2013 09:18 AM, Bernhard Voelker wrote:
+ /* If true (and the -r option is also specified), remove all children
+ of directory arguments, yet retaining the directory itself. */
+ bool
Hi,
On Thu, Nov 21, 2013 at 08:53:47AM -0700, Eric Blake wrote:
On 11/21/2013 04:50 AM, Tormen wrote:
I think I just found a bug in chown... \o/ ;)
I tried:
chown 1001: /tmp/bla
Leading to:
chown: invalid spec: `1001:'
Drop the trailing colon.
... it should be a
On 11/21/2013 05:39 PM, Eric Blake wrote:
On 11/21/2013 10:38 AM, Eric Blake wrote:
On 11/21/2013 10:35 AM, Pádraig Brady wrote:
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing
On 11/21/2013 05:25 PM, Eric Blake wrote:
On 11/21/2013 09:18 AM, Bernhard Voelker wrote:
+ /* If true (and the -r option is also specified), remove all children
+ of directory arguments, yet retaining the directory itself. */
+ bool children_only;
Should --children-only imply -r,
On 21/11/13 17:09, Eric Blake wrote:
But as written, the usage text implies that we can omit both OWNER and
:GROUP and still have a valid call, as in:
chown /tmp/bla
which isn't quite true. Alas, the only way I can see to rewrite the
fact that SOME spec is necessary, while still
On 11/21/2013 04:06 PM, Eric Blake wrote:
Hard to say that it is considerable bloat without seeing a patch; we
already know when the top-level arguments are directories thanks to 'rm -d'.
Here's a draft - not tested more than this:
$ mkdir -p /tmp/dir /tmp/dir/sub
$ touch /tmp/dir/file
On Thu, Nov 21, 2013 at 5:39 AM, Eric Blake ebl...@redhat.com wrote:
On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
...
But that's not what Linda is asking for. She is not asking to pull .
out of under her feet. Instead, she wants a command that will
recursively remove the children of .,
Andreas Schwab wrote:
Eric Blake writes:
so it looks like we have a bug that if OWNER is numeric, we aren't
looking up OWNER's login group.
There may not be a unique uid to user name mapping.
I think that anyone using this would expect it would take the first
one returned. The same that
Eric Blake wrote:
But that's not what Linda is asking for. She is not asking to pull .
out of under her feet.
Actually as I understand it she is expecting the call to succeed if
the system kernel allows it. I believe that is the way rm used to
work before removing '.' was disallowed.
mkdir
On 21/11/13 17:32, Eric Blake wrote:
tag 15945 - notabug
reopen 15945
thanks
No, thank you :)
On 11/21/2013 09:24 AM, Tormen wrote:
Leading to:
chown: invalid spec: `1001:'
Drop the trailing colon.
But I want the same effect than
chown me: /tmp/bla
Ooh, you're right. We DO
On 11/21/2013 10:35 AM, Pádraig Brady wrote:
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing constructs.
Even more generally find(1) could be used to handle arbitrarily
many files and
tag 15945 notabug
thanks
On 11/21/2013 04:50 AM, Tormen wrote:
I think I just found a bug in chown... \o/ ;)
I tried:
chown 1001: /tmp/bla
Leading to:
chown: invalid spec: `1001:'
Drop the trailing colon.
... it should be a bug except if there is a technical detail I am
41 matches
Mail list logo
