bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible chgrp bug


From: Bob Proulx
Subject: Re: Possible chgrp bug
Date: Tue, 11 Sep 2001 14:03:40 -0600

Dave

> I'm emailing to report a possible bug in chgrp.  I am not a linux expert by
> any means, so it is possible that I have misunderstood or misused the
> utility, in which case, apologies in advance.

Thanks for your report.  But what you are seeing is not a bug.

> FYI I am using RedHat 7.1 (Kernel 2.4).  The man page reports the version of
> fileutils to be 4.0.36.
> 
> As "root" I was in a users directory (user "mark") and performed a
>       chown -R mark *
> which worked as expected.  I then did a
>       chgrp -R mark *
> but an "ls -la" showed that the group hadn't changed for hidden . files.
> The owner HAD taken effect on the hidden . files.

Seeing a difference in behavior between chown and chgrp is
unexpected.  They both should have modified the same files.  But
because of the misunderstanding of the behavior of '*' and '.' I don't
know if this is a real problem or not.

> I believe this to be a bug.  The following I am not sure whether it is a bug
> or my own stupid mis-use:

The '*' is not expanding the way you think it should.  But it is
expanding the way unix shells define it to be expanded.  If you are
using bash then you can read the bash documentation in the "Filename
Expansion" section for more details.

     When a pattern is used for filename generation, the character `.' at
  the start of a filename or immediately following a slash must be
  matched explicitly, unless the shell option `dotglob' is set.  When
  matching a file name, the slash character must always be matched
  explicitly.  In other cases, the `.' character is not treated specially.

In a nutshell the '*' matches many but not all characters in
filenames.  Since it matches a glob of characters this is called
globbing and the '*' is known as the glob character.  But most
importantly it will not match .files unless you specifically start the
pattern with a dot.  In that case it will.

> I then tried doing
>       chgrp -R mark .*
> to change the . files.  I realised quite quickly that this was taking longer
> than I expected and CTRL-C'ed it.  I found that this command had moved into
> the parent (..) directory and was starting to change the group of all files
> in all other users home directory.  Luckily I stopped it before it had
> processed more than a few directories.  I am not sure if this is expected
> behaviour or another bug.

That is also expected behavior.  You specifically told it to use .*
and so that matched '..' as well.  The '..' is also a directory and it
can recurse down it.  Which it did.

If you want to avoid .. but still get .files the traditional method
would be to use .??*.  The '?' never matches a dot.  That almost works
everywhere.  The new method would be to use .[!.]* which matches files
starting with a . without a dot as the second character.

In none of these cases did chown or chgrp have any knowledge of this.
It was expanded by the shell prior to command execution.  This is
generally a good thing in unix.  It allows the shell to handle the
interface for all commands and so they all behave the same.

You can check on what the shell does with the 'echo' command.  Try
using echo to print out what you are telling the commands to do.
Experimenting with echo is a good way to learn what the shell does to
expand the command line.  I think you will find the results
interesting.

  echo chgrp -R mark *
  echo chgrp -R mark .*
  echo chgrp -R mark .[!.]*

For further information I would suggest one of the many shell
programming books.  There are so many that I can't really suggest one
over another.  My favorite is the 1987, "The UNIX System V Environment",
by Stephen R. Bourne.  But that is dated now.  The, nutshell handbook
series of books from O'Reilly are generally very good.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]