From owner-freebsd-standards@FreeBSD.ORG Wed Mar 30 23:19:20 2005 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5722916A4CE for ; Wed, 30 Mar 2005 23:19:20 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87E1543D5C for ; Wed, 30 Mar 2005 23:19:19 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip68-230-188-82.dc.dc.cox.net [68.230.188.82]) (authenticated bits=0) by pittgoth.com (8.12.10/8.12.10) with ESMTP id j2UNJIMp070445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 30 Mar 2005 18:19:18 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Wed, 30 Mar 2005 18:19:04 -0500 From: Tom Rhodes To: standards@FreeBSD.org Message-ID: <20050330181904.16519571@mobile.pittgoth.com> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Patch for cp(1) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 23:19:20 -0000 Hi -standards. What do people think of the following patch to cp.c: Index: cp.c =================================================================== RCS file: /home/ncvs/src/bin/cp/cp.c,v retrieving revision 1.51 diff -u -r1.51 cp.c --- cp.c 10 Jan 2005 08:39:21 -0000 1.51 +++ cp.c 30 Mar 2005 15:42:43 -0000 @@ -84,7 +84,7 @@ PATH_T to = { to.p_path, emptystring, "" }; int fflag, iflag, nflag, pflag, vflag; -static int Rflag, rflag; +static int Rflag; volatile sig_atomic_t info; enum op { FILE_TO_FILE, FILE_TO_DIR, DIR_TO_DNE }; @@ -135,7 +135,7 @@ pflag = 1; break; case 'r': - rflag = 1; + Rflag = 1; break; case 'v': vflag = 1; @@ -151,16 +151,7 @@ usage(); fts_options = FTS_NOCHDIR | FTS_PHYSICAL; - if (rflag) { - if (Rflag) - errx(1, - "the -R and -r options may not be specified together."); - if (Hflag || Lflag || Pflag) - errx(1, - "the -H, -L, and -P options may not be specified with the -r option."); - fts_options &= ~FTS_PHYSICAL; - fts_options |= FTS_LOGICAL; - } + if (Rflag) { if (Hflag) fts_options |= FTS_COMFOLLOW; @@ -224,12 +215,12 @@ * the initial mkdir(). */ if (r == -1) { - if (rflag || (Rflag && (Lflag || Hflag))) + if ((Rflag && (Lflag || Hflag)) stat(*argv, &tmp_stat); else lstat(*argv, &tmp_stat); - if (S_ISDIR(tmp_stat.st_mode) && (Rflag || rflag)) + if (S_ISDIR(tmp_stat.st_mode) && (Rflag) type = DIR_TO_DNE; else type = FILE_TO_FILE; @@ -414,7 +405,7 @@ } break; case S_IFDIR: - if (!Rflag && !rflag) { + if (!Rflag) { warnx("%s is a directory (not copied).", curr->fts_path); (void)fts_set(ftsp, curr, FTS_SKIP); So, why/what am I doing: My copy of SuSv3 states that -r is about to become obsolete; The -r option fails (actually hangs) when trying to copy a fifo file within a directory. It does this on both CURRENT, STABLE and SunOS 5.9. The idea was to make -r a synonym for -R, which works in all of these cases. I plan to fix the manual page as -r is not historical, it was implemenation dependent. Comments/suggestions? Yes, manual page commit would done together of course. Also reviewed to be cool by das and philip. :) -- Tom Rhodes