bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Pádraig Brady]

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,
 + _(refusing to remove %s or %s directory: skipping %s),
 + quote_n (0, .), quote_n (1, ..),
 + quote_n (2, ent-fts_path));

That's a good clarification. Please push.

thanks!
Pádraig.

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Pádraig Brady]

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 unless someone comes up with a better wording.
 
  But I'm also starting to think we should add a new long
 option --no-preserve-dot, similar to how --no-preserve-root can be used
 to work around the restriction.  Then people that want to can create an
 alias or other wrapper around rm to get the non-nanny behavior, while
 the default behavior still complies with POSIX.
 
 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 ..
 
 However, as it's possible to pass the canonicalized file name of .
 or .. to rm(1), I'm not yet convinced that it warrants adding a
 new --no-preserve-dot-or-dotdot (and for symmetry reasons a new
 --preserve-dot-or-dotdot) option.

I would say this does not need an option for the reason you describe.

thanks,
Pádraig.

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Linda Walsh]

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 to create a copy of what is in dir a
inside of a pre-existing dir b.  In dir a are files and
sub dirs.  On some of those subdirs, other file systems *may*
be mounted -- EITHER in the dir immediately under a, OR lower:

I would use cp -alx a/. b/.

Sometime later, I want to remove the contents of 'b' w/o disturbing
'b'.  'b' may have file systems mounted under it or not.
Again, I would use the dot notation.  rm -fxr b/.

rm -fxr path/b, as you suggest isn't the same thing.

Directories are containers.  I want to work just with the
contents -- not the directory itself.

So how do I override the refusal -- and get the same results?

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 used to handle arbitrarily
 many files and commands that don't support recursion internally.

 Could you explain why rm would get this and say chmod would not?
 
 Ideally, any command that implements recursion should have the option to
 operate on children only.  You are correct that rm should not be special
 in this regards, so yes, I think chmod should also get it.

Which says that maybe gnulib's fts module needs a new flag for recursion
without visiting the root node, rather than adding ad-hoc root node
exclusion into all clients.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 it succeeds.

No, if there were no nanny rule, then there is a difference between:

rm -r $PWD # Deletes dir out of under your feet, if allowed
rm -r .# leaves dir empty

rmdir(pwd) can succeed (true on Linux; it can also fail if the system
deems that a directory in use as a pwd can't be deleted - mingw is one
such system)
rmdir(.) MUST fail (rmdir(2) can only delete a directory if specified
by a non-. name)

Linda was asking to delete children but NOT the directory; she did NOT
want to use 'rm -r $PWD' because that attempts (and may succeed) at
deleting pwd.  But she was ticked off that the nanny rules on .
prevented recursion from even being attempted.

 
 Agreed.  And I rather like the --children-only semantics you have
 proposed.  It creates a generally useful behavior regardless of other
 things.  It isn't quite the same as bypassing the nanny rule for '.'

Indeed - and if we still keep the nanny rule, then Linda would have to
use 'rm -r --children-only $PWD' because the nanny rule would block 'rm
-r --children-only .'; but since --children-only takes us out of the
realm of POSIX, we can also use it to skip the nanny rule.

 but it solves the issue while doing something generally useful at the
 same time.  Have to like it when it is two birds with one stone. :-)

Yay - I'm glad that we appear to have come to what seems to be a useful
conclusion.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Pádraig Brady]

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 ..
 
 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 ., 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 rmdir(.) and letting rm succeed).  Right now, the nanny rule of
 POSIX is preventing the recursion, so you have to use contortions such
 as the POSIX 'find . -depth ! -name . -exec rm {} +'.  So I think it IS
 useful to add an option that forces 'rm -r' to bypass the nanny rule and
 recurse on ..
 
 Maybe naming it --no-preserve-dot is wrong.  Maybe a better name is 'rm
 -r --children-only .'.  At which point, I would much rather see us skip
 the rmdir(.) in order to allow rm to succeed.  And it would also work
 even for non-dot situations: 'rm -r --children-only dir'.  In other
 words, I _do_ see what Linda is asking for, and think it is worth providing.

I'm not that enthusiastic for this new option,
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 commands that don't support recursion internally.

Could you explain why rm would get this and say chmod would not?

thanks,
Pádraig.

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Eric Blake]

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 coreutils chown' :)

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Linda Walsh]

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 handle arbitrarily
many files and commands that don't support recursion internally.

Could you explain why rm would get this and say chmod would not?


Argh!  Feature creep!

The reason that rm should have it but chmod should not is that it is
to work around the POSIX nanny rule around '.' and '..'.  Chmod does
not have such a nanny rule and therefore does not need that option.

...

This is actually the best argument against it.  It is a slippery
slope.  Let's not implement 'find' all over again.


Let's just use '-F' to force rm to adhere to its original depth
first path examination.  -F disallows applying any path related
rules until AFTER depth-first recursive execution has been completed
on the path.

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Jim Meyering]

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 clearer error message would be possible.

 What about the following?

   $ src/rm -r src/.
   src/rm: refusing to remove '.' or '..' directory: skipping 'src/.'

 I didn't want to explicitly mention POSIX here ... it's just to clarify
 that rm(1) does not swallow errors from the kernel like EPERM, etc.

 The texinfo file is enhanced in the patch below, too.
...
 ---
  doc/coreutils.texi |  3 ++-
  src/remove.c   | 12 

Thanks for doing that.
I was a little surprised to see an rm diagnostic change, but no
corresponding change in any test.  Perhaps an opportunity for
increased test coverage?

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Andreas Schwab]

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 44D5 214B 8276 4ED5
And now for something completely different.

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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:

 +++ b/src/remove.h
 @@ -52,6 +52,10 @@ struct rm_options
/* If true, remove empty directories.  */
bool remove_empty_directories;
 
 +  /* 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, rather than being a no-op when -r is
missing?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Tormen]

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.5amd64   GNU core utilities

uname -a
Linux seven 3.10-0.bpo.3-amd64 #1 SMP Debian 3.10.11-1~bpo70+1
(2013-09-24) x86_64 GNU/Linux

echo $SHELL
/bin/zsh

I tried:
chown 1001: /tmp/bla

Leading to:
chown: invalid spec: `1001:'

But as 1001 == me, it should have done a:
chown me: /tmp/bla
(which works just fine).

Is this a bug or a feature ?

... it should be a bug except if there is a technical detail I am
missing here.

Best,

Tormen

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 require some extra checking on arguments,
 because only arguments of type directory are allowed.

That's one idea.  Another idea is to make the option handle directories
specially but have no change for regular files (similar to how 'rm -d'
handles directories specially but has no change for regular files).

 And there'd be some strange corner cases to decide about, e.g. consider
   rm -r --children dir/sub dir
 Should dir/sub be removed/retained in this case? ...

Removed; as always, rm processes command line arguments in order, so
even though dir/sub is left alone after the first argument is processed,
the second argument removes dir/sub without any care in the world what
processing the first argument did.

 Anyhow, handling such cases would add considerable bloat to the code.

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'.

 
 Does anyone know of such an option in other rm(1) implementations?

Not in rm(1) per se, but I _do_ know that the paradigm is common in
other hierarchical based systems.  For example, in libvirt, you can
maintain a tree-based view of snapshots, and for removing a branch of
that tree, libvirt exposes the option to either remove a snapshot and
all its children, or to just remove the children but leave the snapshot
intact.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Eric Blake]

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] as optional, but in reality it
is mandatory if ':' is present.  So we definitely need to change
'[:[GROUP]]' to '[:GROUP]'.

The minor group stems from a GNU extension.  POSIX requires that the
OWNER portion is mandatory:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html

But as a GNU extension, we allow it to be empty to allow for:

  chown :1001 /tmp/bla   # change group only

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 highlighting the GNU
extension of omitting OWNER, is to split the usage into two lines:

Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
  or:  chown [OPTION]... :GROUP FILE...

Thoughts?  Should we reopen this bug to track the doc bug[s]?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Eric Blake]

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 sense.  Rather
than being a blanket invalid spec: `1001:' it should say something
like unable to determine default group for user `1001'

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Bernhard Voelker]

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 rmdir(.) and letting rm succeed).  Right now, the nanny rule of
POSIX is preventing the recursion, so you have to use contortions such
as the POSIX 'find . -depth ! -name . -exec rm {} +'.  So I think it IS
useful to add an option that forces 'rm -r' to bypass the nanny rule and
recurse on ..


I realized the difference when reading her latest message. (It's often
hard to follow her; sorry Linda.)


Maybe naming it --no-preserve-dot is wrong.  Maybe a better name is 'rm
-r --children-only .'.  At which point, I would much rather see us skip
the rmdir(.) in order to allow rm to succeed.  And it would also work
even for non-dot situations: 'rm -r --children-only dir'.  In other
words, I_do_  see what Linda is asking for, and think it is worth providing.


Okay, I see the point: so now we're talking about the following
(with . to be allowed instead of 'dir'):

  $ mkdir dir dir/sub

  $ touch dir/file dir/sub/another

  $ rm -rv --children-only dir
  removed 'dir/file'
  removed 'dir/sub/another'
  removed directory: 'dir/sub'
  retaining directory argument due to --children-only: 'dir'

  $ ls -d dir
  dir

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 --children-only would require some extra checking on arguments,
because only arguments of type directory are allowed.
And there'd be some strange corner cases to decide about, e.g. consider
  rm -r --children dir/sub dir
Should dir/sub be removed/retained in this case? ...
Anyhow, handling such cases would add considerable bloat to the code.

Does anyone know of such an option in other rm(1) implementations?

Have a nice day,
Berny

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Eric Blake]

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 - name) necessary when
 calling chown with an uid.
 The ls then does the lookup to translate the ID in a name then.
 And so the ls could run into the mapping problem...  or chown if called
 with a username.
 
 Or is it the other way round ?

No, you have it right - stat() stores only uid, and ls(1) does a name
lookup for printing the (more precisely, a) username associated with
that id.

 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 mapping problem when using numerical IDs
 for users/groups.
 Only when called with names.

Not true - we still have two potential lookup problems.  One is that
that there may be NO name associated with ID (ls -l just falls back to
listing id, but in the chmod case, we can't do a default login group
lookup if we don't have a name).  Try as root:

# touch /tmp/f
# chown 12345 /tmp/f
# ls -l /tmp/f
-rw-r--r--. 1 12345 root 0 Nov 21 13:51 /tmp/f

The other is that even if a name is associated with an ID (whether the
only name, or whether the first name out of multiple that map to the
id), the default login group lookup for that name may fail (but that's
true even if we didn't first do a uid-name lookup).

Either way, my point remains - we should have a saner error message if
we are unable to determine a default login group for a given user
identification, rather than just declaring the entire '1001:' an invalid
spec.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Tormen]

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 mapping problem when using numerical IDs
 for users/groups.
 Only when called with names.
 Not true - we still have two potential lookup problems.  One is that
 that there may be NO name associated with ID (ls -l just falls back to
 listing id, but in the chmod case, we can't do a default login group
 lookup if we don't have a name).
Yes of course for the login group lookup needs the name! - Dough.
 Either way, my point remains - we should have a saner error message if
 we are unable to determine a default login group for a given user
 identification, rather than just declaring the entire '1001:' an invalid
 spec.
+1 for the nice error message :)

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Bob Proulx]

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 commands that don't support recursion internally.
  
  Could you explain why rm would get this and say chmod would not?

Argh!  Feature creep!

The reason that rm should have it but chmod should not is that it is
to work around the POSIX nanny rule around '.' and '..'.  Chmod does
not have such a nanny rule and therefore does not need that option.

 Ideally, any command that implements recursion should have the option to
 operate on children only.  You are correct that rm should not be special
 in this regards, so yes, I think chmod should also get it.

This is actually the best argument against it.  It is a slippery
slope.  Let's not implement 'find' all over again.

Bob

bug#15945: closed (Re: bug#15945: chown: Does now allow setting user and users login group with numerical user ID)

[Tormen]

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 ?


==


Wording in man chown:

DESCRIPTION
   This manual page documents the GNU version of chown.  chown
changes the
   user and/or group ownership of each given file.  If only  an 
owner  (a
   user  name or numeric user ID) is given, that user is made the
owner of
   each given file, and the files' group is not changed.  [1] If the
owner  is
   followed  by  a  colon  and a group name (or numeric group ID),
with no
   spaces between them, the group ownership of the  files  is 
changed  as
   well.  [2] If a colon but no group name follows the user name,
that user is
   made the owner of the files and the group of the files  is 
changed  to
   that  user's  login  group.   If the colon and group are given,
but the
   owner is omitted, only the group of the files is changed; in this
case,
   chown  performs  the same function as chgrp.  If only a colon is
given,
   or if the entire operand is empty, neither the owner nor the 
group  is
   changed.

[1] At this point owner is referenced as name or numeric ID.

[2] At this point you do not reprecise owner but only state about the
additional colon : -- so one must expect owner still to be name or
numeric ID.


Best,

Tormen


On 21/11/13 16:54, GNU bug Tracking System wrote:
 Your bug report

 #15945: chown: Does now allow setting user and users login group with 
 numerical user ID

 which was filed against the coreutils package, has been closed.

 The explanation is attached below, along with your original report.
 If you require more details, please reply to 15...@debbugs.gnu.org.

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Tormen]

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 effect than
chown me: /tmp/bla
so changing:
(1) the owner of /tmp/bla to user me
(2) the group of /tmp/bla to the login-group of user me

chown me /tmp/bla
should only do (1), no ?


 If you provide a colon, you MUST also provide a group spec.  Per 'chown
 --help', the syntax is:
  chown [OPTION]...  [OWNER][:[GROUP]] FILE...
 so these are valid:
  chown 1001 /tmp/bla# change owner only
  chown :1001 /tmp/bla   # change group only
  chown 1001:1001 /tmp/bla   # change both
 but this is invalid:
  chown 1001: /tmp/bla   # '' is not a valid group
Yes, but when you execute:
chown me: /tmp/bla

as group is '' as well and it is not a problem.

I don't see any problem / ambiguity in allowing both:
chown me: /tmp/bla
chown 1001: /tmp/bla

especially as:
chown me /tmp/bla
chown 1001 /tmp/bla
are both possible and provide the same result.

So for the trailing : case it should be (flexibly/convieniently) work
the same, no ?

Tormen

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Linda Walsh]

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 before removing '.' was disallowed.


Um... I *expect* .* to be unremoveable.  The entries . and .. are
required in all directories.  These are required for a properly structured
directory.   The only way to remove . and .. entries in
a directory is to remove the directory name itself:

   rm -fr /tmp/mytmp

would remove mytmp + any contents  (including the structural entries . and
.. inside 'mytmp' .  However, if I type rm -fr /tmp/mytmp/. As is 
implemented
in most OS's, it would do a depth first traversal removal.  At least on linux,
you couldn't remove . as it is your current position.  You can remove the 
directory

which . is in as you show below:


  mkdir /tmp/testdir
  cd /tmp/testdir
  rmdir /tmp/testdir
  echo $?
  0
  ls -ldog /tmp/testdir
  ls: cannot access /tmp/testdir: No such file or directory
  /bin/pwd
  /bin/pwd: couldn't find directory entry in ‘..’ with matching i-node



So I expect anything containing . foo/. to FAIL -- but only AFTER it has 
already
done depth first traversal.   Adding the -f flag was to silence the error and
have the exit code set to '0' due to any failures.

Posix mandates checking . *first*. when doing a recursive removal with -f..

So how about using -F as a gnu extension to ignore that case?

That POSIX would have declared rm -fr . illegal on nanny grounds goes against
the original spirit of why the -f flag was added in the 1st place.  It meant
to force the issue, *if* possible  (if permissions allowed).  I have
no issue with error messages due to permission problems -- as they'd indicate
the directory wasn't cleaned out -- rm -fr . was to clean out the contents
of a dir to ready it for some reused.

So I propose adding a -F to force rm to adhere to its original algorithm and
override the POSIX restriction (as well as serving the purpose of -f to
force any removals.



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 it succeeds.


you didn't remove .   You removed the directory . is
contained in.  A direct removal of . or .. should be disallowed
because they are a required part of any directory.  To removed them
you must remove the directory by name, but addressing the structural
entries must fail.

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Bob Proulx]

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

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Bob Proulx]

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 defended it because I often used this
on various systems to set the default group of a user.  Because some
systems are configured with user-private-groups where the user is in a
private group while on other systems the user is in a shared users
group.  Using 'chown foo: file' was a nice way to set the group to
foo's default group without needing to figure out what that group was
ahead of time.  I don't know when it was introduced into GNU chown but
at the least I had been using it extensively.

 so it looks like we have a bug that if OWNER is numeric, we aren't
 looking up OWNER's login group.

Seems that way.

Bob

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Eric Blake]

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 by a colon and a GROUP (a group name or
 numeric group ID), with no spaces between them, the group ownership
 of the files is changed as well (to GROUP).

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.

so it looks like we have a bug that if OWNER is numeric, we aren't
looking up OWNER's login group.

Which means my earlier comments aren't quite correct - the existing use
of [:[GROUP]] in usage text is correct.  But I _still_ think we need to
split into two lines to make it obvious that the argument itself is
mandatory, as in:

Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
  or:  chown [OPTION]... :[GROUP] FILE...

or even rewrite it along the lines of the info page:

Usage: chown [OPTION]... NEWSPEC FILE...

and document that NEWSPEC is [OWNER][:[GROUP]]

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Tormen]

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 (intentionally) not as
 comprehensive as 'info coreutils chown' :)

I wonder how old the bug is (my bug-hunters pride talking)...

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Jim Meyering]

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 tested more than this:

   $ mkdir -p /tmp/dir /tmp/dir/sub
   $ touch /tmp/dir/file /tmp/dir/sub/other

   $ src/rm -rv --child /tmp/dir
   removed ‘/tmp/dir/file’
   removed ‘/tmp/dir/sub/other’
   removed directory: ‘/tmp/dir/sub’
   src/rm: skipping ‘/tmp/dir’, due to --children-only

   $ src/rm -rv --child /tmp/dir
   src/rm: skipping ‘/tmp/dir’, due to --children-only

   $ src/rm -rv --child /tmp/dir/.
   src/rm: skipping ‘/tmp/dir/.’, due to --children-only


 Have a nice day,
 Berny

 From 03d58cc281c6155d50be9b770bbac7bf73cdaf92 Mon Sep 17 00:00:00 2001
 From: Bernhard Voelker m...@bernhard-voelker.de
 Date: Thu, 21 Nov 2013 17:11:27 +0100
 Subject: [PATCH] rm: add --children-only option

 FIXME
 ---
  src/mv.c |  1 +
  src/remove.c | 29 -
  src/remove.h |  4 
  src/rm.c |  9 +
  4 files changed, 38 insertions(+), 5 deletions(-)

 diff --git a/src/mv.c b/src/mv.c
 index 1cfcd82..36e70a4 100644
 --- a/src/mv.c
 +++ b/src/mv.c
 @@ -74,6 +74,7 @@ rm_option_init (struct rm_options *x)
  {
x-ignore_missing_files = false;
x-remove_empty_directories = true;
 +  x-children_only = false;
x-recursive = true;
x-one_file_system = false;

 diff --git a/src/remove.c b/src/remove.c
 index 3d386cf..eb05cb4 100644
 --- a/src/remove.c
 +++ b/src/remove.c
 @@ -439,8 +439,10 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const
 *x)
  {

/* POSIX says:
   If the basename of a command line argument is . or ..,
 - diagnose it and do nothing more with that argument.  */
 -  if (dot_or_dotdot (last_component (ent-fts_accpath)))
 + diagnose it and do nothing more with that argument.
 + FIXME: mention --children-only.  */
 +  if (! x-children_only
 +   dot_or_dotdot (last_component (ent-fts_accpath)))
  {
error (0, 0,

   _(refusing to remove %s or %s directory: skipping
 %s),
 @@ -468,9 +470,17 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const
 *x)

  if (s == RM_OK  is_empty_directory == T_YES)
{
 -/* When we know (from prompt when in interactive mode)
 -   that this is an empty directory, don't prompt twice.  */
 -s = excise (fts, ent, x, true);
 +if (FTS_ROOTLEVEL == ent-fts_level  x-children_only)
 +  {
 +error (0, 0, _(skipping %s, due to --children-only),
 +   quote (ent-fts_path));
 +  }
 +else
 +  {
 +/* When we know (from prompt when in interactive mode)
 +   that this is an empty directory, don't prompt twice.  */
 +s = excise (fts, ent, x, true);
 +  }
  fts_skip_tree (fts, ent);
}

 @@ -492,6 +502,15 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const
 *x)
  case FTS_NSOK: /* e.g., dangling symlink */
  case FTS_DEFAULT:  /* none of the above */
{
 +if (ent-fts_info == FTS_DP
 + x-children_only
 + FTS_ROOTLEVEL == ent-fts_level)
 +  {
 +mark_ancestor_dirs (ent);
 +error (0, 0, _(skipping %s, due to --children-only),
 +   quote (ent-fts_path));
 +return RM_OK;
 +  }
  /* With --one-file-system, do not attempt to remove a mount point.
 fts' FTS_XDEV ensures that we don't process any entries under
 the mount point.  */
 diff --git a/src/remove.h b/src/remove.h
 index 9ac54d4..248a470 100644
 --- a/src/remove.h
 +++ b/src/remove.h
 @@ -52,6 +52,10 @@ struct rm_options
/* If true, remove empty directories.  */
bool remove_empty_directories;

 +  /* If true (and the -r option is also specified), remove all children
 + of directory arguments, yet retaining the directory itself.  */
 +  bool children_only;
 +
/* Pointer to the device and inode numbers of '/', when --recursive
   and preserving '/'.  Otherwise NULL.  */
struct dev_ino *root_dev_ino;
 diff --git a/src/rm.c b/src/rm.c
 index 7a51eef..0634855 100644
 --- a/src/rm.c
 +++ b/src/rm.c
 @@ -51,6 +51,7 @@ enum
ONE_FILE_SYSTEM,
NO_PRESERVE_ROOT,
PRESERVE_ROOT,
 +  CHILDREN_ONLY,
PRESUME_INPUT_TTY_OPTION
  };

 @@ -78,6 +79,7 @@ static struct option const long_opts[] =

{recursive, no_argument, NULL, 'r'},
{dir, no_argument, NULL, 'd'},
 +  {children-only, no_argument, NULL, CHILDREN_ONLY},
{verbose, no_argument, NULL, 'v'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
 @@ 

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 explicit in the handling of directories also:
 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html

I've filed a bug against POSIX requesting the standardization of 'rm -d':
http://austingroupbugs.net/view.php?id=802

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 falls over in the presence of file names with newline, so
you have to get fancier with find -print0 and xargs -0 to be robust.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 children_only;

 Should --children-only imply -r, rather than being a no-op when -r is
 missing?
 
 I thought about it, but as there's no way to --no-recursive,
 the posibility to alias rm='/bin/rm --children-only' would be void.

Good point (although someone using that as an alias for 'rm' is rather
brave! I'd personally create an alias with a different name than rm to
make it obvious that it doesn't remove the named argument; maybe alias
empty='rm --children-only -r' so that 'empty dir' is a self-describing
command to empty out the contents of dir).  So I'm fine with your
proposal of still needing an explicit -r for it to make a difference.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Erik Auerswald]

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 bug except if there is a technical detail I am
  missing here.
 
 If you provide a colon, you MUST also provide a group spec.  Per 'chown
 --help', the syntax is:
  chown [OPTION]...  [OWNER][:[GROUP]] FILE...
 so these are valid:
  chown 1001 /tmp/bla# change owner only
  chown :1001 /tmp/bla   # change group only
  chown 1001:1001 /tmp/bla   # change both
 but this is invalid:
  chown 1001: /tmp/bla   # '' is not a valid group

Should this be changed to 'chown [OPTION]...  [OWNER][:GROUP] FILE...'
then?

Erik

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Pádraig Brady]

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 constructs.
 Even more generally find(1) could be used to handle arbitrarily
 many files and commands that don't support recursion internally.

 Could you explain why rm would get this and say chmod would not?

 Ideally, any command that implements recursion should have the option to
 operate on children only.  You are correct that rm should not be special
 in this regards, so yes, I think chmod should also get it.
 
 Which says that maybe gnulib's fts module needs a new flag for recursion
 without visiting the root node, rather than adding ad-hoc root node
 exclusion into all clients.

That would be the right way to implement it,
_but_ the disadvantage is that this filtering
option is exposed to the users for all these commands.

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

cheers,
Pádraig.

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Bernhard Voelker]

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, rather than being a no-op when -r is
missing?


I thought about it, but as there's no way to --no-recursive,
the posibility to alias rm='/bin/rm --children-only' would be void.

There are surely other corner cases I didn't think about.
E.g. I was surprised to check for children-only in a second
place in the case dir is already empty.

Have a nice day,
Berny

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Tormen]

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 highlighting the GNU
 extension of omitting OWNER, is to split the usage into two lines:

 Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
   or:  chown [OPTION]... :GROUP FILE...

 Thoughts?  Should we reopen this bug to track the doc bug[s]?

 Alas, ...
Hehe.

I agree, two lines should be the only way to express that
there are 4 possibilities:
chown OWNER
chown OWNER:
chown OWNER:GROUP
chwon :GROUP

But shouldn't all 4 possibilities allow both OWNER and GROUP to be
specified either as NAME or as numerical ID ?

chown OWNERNAME   == chown OWNERID[*]
chown OWNERNAME:  == chown OWNERID:   [**]
chown OWNERNAME:GROUPNAME == chown OWNERID:GROUPID[*]
chwon :GROUPNAME  ==chown :GROUPID [*]

[*] working as expected
[**] NOT working as expected (see my bug report) ... but why ?

Especially as:
chown 1001:mine /tmp/bla
and
chown me:1001 /tmp/bla
works fine!

(with mine == 1001)


Tormen

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Bernhard Voelker]

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 /tmp/dir/sub/other

  $ src/rm -rv --child /tmp/dir
  removed ‘/tmp/dir/file’
  removed ‘/tmp/dir/sub/other’
  removed directory: ‘/tmp/dir/sub’
  src/rm: skipping ‘/tmp/dir’, due to --children-only

  $ src/rm -rv --child /tmp/dir
  src/rm: skipping ‘/tmp/dir’, due to --children-only

  $ src/rm -rv --child /tmp/dir/.
  src/rm: skipping ‘/tmp/dir/.’, due to --children-only

Have a nice day,
Berny

From 03d58cc281c6155d50be9b770bbac7bf73cdaf92 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker m...@bernhard-voelker.de
Date: Thu, 21 Nov 2013 17:11:27 +0100
Subject: [PATCH] rm: add --children-only option

FIXME
---
 src/mv.c |  1 +
 src/remove.c | 29 -
 src/remove.h |  4 
 src/rm.c |  9 +
 4 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/src/mv.c b/src/mv.c
index 1cfcd82..36e70a4 100644
--- a/src/mv.c
+++ b/src/mv.c
@@ -74,6 +74,7 @@ rm_option_init (struct rm_options *x)
 {
   x-ignore_missing_files = false;
   x-remove_empty_directories = true;
+  x-children_only = false;
   x-recursive = true;
   x-one_file_system = false;

diff --git a/src/remove.c b/src/remove.c
index 3d386cf..eb05cb4 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -439,8 +439,10 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options 
const *x)

 {
   /* POSIX says:
  If the basename of a command line argument is . or ..,
- diagnose it and do nothing more with that argument.  */
-  if (dot_or_dotdot (last_component (ent-fts_accpath)))
+ diagnose it and do nothing more with that argument.
+ FIXME: mention --children-only.  */
+  if (! x-children_only
+   dot_or_dotdot (last_component (ent-fts_accpath)))
 {
   error (0, 0,
  _(refusing to remove %s or %s directory: 
skipping %s),
@@ -468,9 +470,17 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options 
const *x)


 if (s == RM_OK  is_empty_directory == T_YES)
   {
-/* When we know (from prompt when in interactive mode)
-   that this is an empty directory, don't prompt twice.  */
-s = excise (fts, ent, x, true);
+if (FTS_ROOTLEVEL == ent-fts_level  x-children_only)
+  {
+error (0, 0, _(skipping %s, due to --children-only),
+   quote (ent-fts_path));
+  }
+else
+  {
+/* When we know (from prompt when in interactive mode)
+   that this is an empty directory, don't prompt twice.  */
+s = excise (fts, ent, x, true);
+  }
 fts_skip_tree (fts, ent);
   }

@@ -492,6 +502,15 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options 
const *x)

 case FTS_NSOK: /* e.g., dangling symlink */
 case FTS_DEFAULT:  /* none of the above */
   {
+if (ent-fts_info == FTS_DP
+ x-children_only
+ FTS_ROOTLEVEL == ent-fts_level)
+  {
+mark_ancestor_dirs (ent);
+error (0, 0, _(skipping %s, due to --children-only),
+   quote (ent-fts_path));
+return RM_OK;
+  }
 /* With --one-file-system, do not attempt to remove a mount point.
fts' FTS_XDEV ensures that we don't process any entries under
the mount point.  */
diff --git a/src/remove.h b/src/remove.h
index 9ac54d4..248a470 100644
--- a/src/remove.h
+++ b/src/remove.h
@@ -52,6 +52,10 @@ struct rm_options
   /* If true, remove empty directories.  */
   bool remove_empty_directories;

+  /* If true (and the -r option is also specified), remove all children
+ of directory arguments, yet retaining the directory itself.  */
+  bool children_only;
+
   /* Pointer to the device and inode numbers of '/', when --recursive
  and preserving '/'.  Otherwise NULL.  */
   struct dev_ino *root_dev_ino;
diff --git a/src/rm.c b/src/rm.c
index 7a51eef..0634855 100644
--- a/src/rm.c
+++ b/src/rm.c
@@ -51,6 +51,7 @@ enum
   ONE_FILE_SYSTEM,
   NO_PRESERVE_ROOT,
   PRESERVE_ROOT,
+  CHILDREN_ONLY,
   PRESUME_INPUT_TTY_OPTION
 };

@@ -78,6 +79,7 @@ static struct option const long_opts[] =

   {recursive, no_argument, NULL, 'r'},
   {dir, no_argument, NULL, 'd'},
+  {children-only, no_argument, NULL, CHILDREN_ONLY},
   {verbose, no_argument, NULL, 'v'},
   {GETOPT_HELP_OPTION_DECL},
   {GETOPT_VERSION_OPTION_DECL},
@@ -156,6 +158,8 @@ Remove (unlink) the FILE(s).\n\
   --preserve-root   do not remove '/' (default)\n\
   -r, -R, --recursive   remove directories and their contents 
recursively\n\

   -d, --dir 

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Jim Meyering]

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 ., 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 rmdir(.) and letting rm succeed).  Right now, the nanny rule of
 POSIX is preventing the recursion, so you have to use contortions such
 as the POSIX 'find . -depth ! -name . -exec rm {} +'.  So I think it IS
 useful to add an option that forces 'rm -r' to bypass the nanny rule and
 recurse on ..

 Maybe naming it --no-preserve-dot is wrong.  Maybe a better name is 'rm
 -r --children-only .'.  At which point, I would much rather see us skip
 the rmdir(.) in order to allow rm to succeed.  And it would also work
 even for non-dot situations: 'rm -r --children-only dir'.  In other
 words, I _do_ see what Linda is asking for, and think it is worth providing.

Thanks for clarifying, Eric.  I am open to the idea.  Amusingly,
when I first read your suggestion for --children-only, I thought,
That's backwards, shouldn't it be '--adults-only' to go with the
no-nanny semantics? Of course, children refers to tree parent/child
relationship, so would make sense in the manual, where there's no
talk of removing this nanny-like safeguard.  But then I wondered about
non-directory arguments, and how the implied semantics of --children-only
applies (or not) to them.  I don't particularly like the idea of adding
the long-named --(no-)?preserve-dot-or-dot-dot, because that would
render ambiguous any existing use of --(no-)?preserve- and all shorter
abbreviations of --(no-)?preserve-root.

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Bob Proulx]

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 happens right now in a normal system.
The same name that 'ls -l' would return.  We don't worry that 'ls -l'
might be mapping a name that might not be unique and shouldn't here
either.

I realize that 'nscd' breaks that long standing assumption that order
matters by returning one randomly.  I consider that a bug in nscd.

Bob

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Bob Proulx]

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 /tmp/testdir
  cd /tmp/testdir
  rmdir /tmp/testdir
  echo $?
  0
  ls -ldog /tmp/testdir
  ls: cannot access /tmp/testdir: No such file or directory
  /bin/pwd
  /bin/pwd: couldn't find directory entry in ‘..’ with matching i-node

That is fine in a flow such as a test flow or other where the action
is cleaning up on an exit for example.  Or in other cases.  It might
be making a new directory and changing to it afterward.  Or something
else that makes sense in that case.

 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 it succeeds.

 Right now, the nanny rule of POSIX is preventing the recursion, so
 you have to use contortions such as the POSIX 'find . -depth ! -name
 . -exec rm {} +'.  So I think it IS useful to add an option that
 forces 'rm -r' to bypass the nanny rule and recurse on ..

Agreed.

 Maybe naming it --no-preserve-dot is wrong.  Maybe a better name is 'rm
 -r --children-only .'.  At which point, I would much rather see us skip
 the rmdir(.) in order to allow rm to succeed.  And it would also work
 even for non-dot situations: 'rm -r --children-only dir'.  In other
 words, I _do_ see what Linda is asking for, and think it is worth providing.

Agreed.  And I rather like the --children-only semantics you have
proposed.  It creates a generally useful behavior regardless of other
things.  It isn't quite the same as bypassing the nanny rule for '.'
but it solves the issue while doing something generally useful at the
same time.  Have to like it when it is two birds with one stone. :-)

Bob

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Tormen]

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 document that:
I started wondering if I missed something extremely obvious here ;)

 Which means my earlier comments aren't quite correct - the existing use
 of [:[GROUP]] in usage text is correct.  But I _still_ think we need to
 split into two lines to make it obvious that the argument itself is
 mandatory, as in:

 Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
   or:  chown [OPTION]... :[GROUP] FILE...

 or even rewrite it along the lines of the info page:

 Usage: chown [OPTION]... NEWSPEC FILE...

 and document that NEWSPEC is [OWNER][:[GROUP]]
... and mention that either OWNER or GROUP needs to be present ;)

But I prefer the 2 lines ... more concise and allows to quickly grasp
the meaning (IMHO).

Tormen

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Eric Blake]

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 commands that don't support recursion internally.
 
 Could you explain why rm would get this and say chmod would not?

Ideally, any command that implements recursion should have the option to
operate on children only.  You are correct that rm should not be special
in this regards, so yes, I think chmod should also get it.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15945: chown: Does now allow setting user and users login group with numerical user ID

[Eric Blake]

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
 missing here.

If you provide a colon, you MUST also provide a group spec.  Per 'chown
--help', the syntax is:
 chown [OPTION]...  [OWNER][:[GROUP]] FILE...
so these are valid:
 chown 1001 /tmp/bla# change owner only
 chown :1001 /tmp/bla   # change group only
 chown 1001:1001 /tmp/bla   # change both
but this is invalid:
 chown 1001: /tmp/bla   # '' is not a valid group

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature