Jim Meyering wrote:
> Ondřej Vašík <[EMAIL PROTECTED]> wrote:
> > Throwing out "--changes" should be ok, if user wants to be informed, he
> > can parse verbose output easily and common case is to use it without
> > verbose mode at all. Anyway --verbose output is affected by this "issue"
> > as well, so I would prefer to
> > 1) depricate --changes option as it could be substituted by --verbose
> > and grep
> > 2) fix the verbose output to show correct output in every case where it
> > is possible. E.g. if the stat fails, it should inform the user that the
> > mode/owner/whatever is unknown. E.g. SGID bit case or stat failed is the
> > thing where user should be informed in verbose mode about something
> > unusual.
> 
> Actually, I was thinking of making --verbose output *less* informative,
> so that it can be truthful, albeit less informative, without adding
> extra stat/lstat calls.  Sort of like chcon, which says simply
> 
>   changing security context of FILE
> 
> While I do see the down-side of doing that, it seems better to print
> less information, with a guarantee of no lies, than to print
> usually-true messages along with the occasional untruth.

For me verbose mode is something useful to track problems. Therefore I
do prefer more informations there. Common usage of
chown/chmod/chgrp/chcon utilities is without --verbose/--changes mode,
so it would affect very low (close to zero) amount of users anyway.
 
I guess burden of of additional stat/lstat calls could be acceptable for
some kind of very verbose mode as it doesn't affect common users at all
and makes tracking of problems easier. Even for the price of potentially
untruth informations in very rare cases - if that risk is mentioned in
documentation.

Greetings,
         Ondřej

Attachment: signature.asc
Description: Toto je digitálně podepsaná část zprávy

_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to