Re: mtree again

2000-09-24 Thread Gerhard Sittig
On Sat, Sep 23, 2000 at 16:02 -0700, Marcel Moolenaar wrote: "Andrey A. Chernov" wrote: [ ... mtree getopts switch code ... ] Is their any harm in just keeping the -P flag as a no-op and optionally remove it at some later time (for backward compatibility)? That's where I jumped in

Re: mtree again

2000-09-23 Thread Marcel Moolenaar
"Andrey A. Chernov" wrote: --- usr.sbin/mtree/mtree.c.orig Thu Jul 27 07:36:02 2000 +++ usr.sbin/mtree/mtree.c Fri Sep 15 04:00:46 2000 [snip] @@ -115,10 +119,6 @@ case 'q': qflag = 1; break; - case 'P':

Re: mtree again

2000-09-23 Thread Warner Losh
In message [EMAIL PROTECTED] Marcel Moolenaar writes: : Is their any harm in just keeping the -P flag as a no-op and optionally : remove it at some later time (for backward compatibility)? -P is non-standard, was introduced only in July and therefore we don't need to keep it around for any

Re: mtree again

2000-09-23 Thread Garrett Wollman
On Sat, 23 Sep 2000 16:02:48 -0700, Marcel Moolenaar [EMAIL PROTECTED] said: Is their any harm in just keeping the -P flag as a no-op and optionally remove it at some later time (for backward compatibility)? We should try to be consistent with POSIX.1-200x as much as possible. -GAWollman

Re: mtree again

2000-09-23 Thread Andrey A. Chernov
On Sat, Sep 23, 2000 at 09:44:21PM -0400, Garrett Wollman wrote: On Sat, 23 Sep 2000 16:02:48 -0700, Marcel Moolenaar [EMAIL PROTECTED] said: Is their any harm in just keeping the -P flag as a no-op and optionally remove it at some later time (for backward compatibility)? We should try

Re: mtree again

2000-09-15 Thread Gerhard Sittig
On Fri, Sep 15, 2000 at 04:39 +0400, Andrey A. Chernov wrote: [ ... change mtree(1) physical vs logical traversal ... ] [ ... mtree.c diff ...] @@ -170,7 +170,7 @@ usage() { (void)fprintf(stderr, -"usage: mtree [-PUcdeinqrux] [-f spec] [-K key] [-k key] [-p path] [-s seed]\n"

mtree again

2000-09-14 Thread Andrey A. Chernov
Is there any progress in mtree fixing process? I think there is acceptable solution, in following steps: 1) Return mtree defaults. 2) Add -L 3) Add ${MTREE_FOLLOW_LINKS} to mtree calls (which expands to nothing in old systems, so we not broke anything in the transition process) 4) Add

Re: mtree again

2000-09-14 Thread Warner Losh
In message [EMAIL PROTECTED] "Andrey A. Chernov" writes: : Is there any progress in mtree fixing process? It hasn't been high on my list. I'd be happy to review patches, however. : I think there is acceptable solution, in following steps: : : 1) Return mtree defaults. : 2) Add -L : 3) Add

Re: mtree again

2000-09-14 Thread Andrey A. Chernov
On Thu, Sep 14, 2000 at 05:41:46PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "Andrey A. Chernov" writes: : Is there any progress in mtree fixing process? It hasn't been high on my list. I'd be happy to review patches, however. Here it is: --- usr.sbin/mtree/mtree.c.orig Thu