From owner-freebsd-standards@FreeBSD.ORG Mon Mar 28 11:01:47 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 6B7E216A508 for ; Mon, 28 Mar 2005 11:01:47 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4509443D31 for ; Mon, 28 Mar 2005 11:01:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j2SB1lLN035551 for ; Mon, 28 Mar 2005 11:01:47 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j2SB1jHK035545 for freebsd-standards@freebsd.org; Mon, 28 Mar 2005 11:01:45 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Mar 2005 11:01:45 GMT Message-Id: <200503281101.j2SB1jHK035545@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you 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: Mon, 28 Mar 2005 11:01:47 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string p [2002/02/25] standards/35307standards standard include files are not standard c o [2002/12/13] kern/46239 standards posix semaphore implementation errors o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/06/18] kern/53447 standards poll(2) semantics differ from susV3/POSIX o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2004/01/01] standards/60772standards _Bool and bool should be unsigned o [2004/11/03] standards/73500standards 'set +o' in /bin/sh does not include unse o [2005/03/03] standards/78357standards getaddrinfo() doesn't appear to support A o [2005/03/09] standards/78650standards ttyname_r() is not standards compliant o [2005/03/16] standards/78907standards does not define pthread typ 12 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/01/24] standards/24590standards timezone function not compatible witn Sin s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public p [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant o [2002/02/27] misc/35381 standards incorrect floating-point display of large s [2002/03/19] standards/36076standards Implementation of POSIX fuser command o [2002/06/14] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] kern/40378 standards stdlib.h gives needless warnings with -an p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/25] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/07/31] standards/55112standards glob.h, glob_t's gl_pathc should be "size o [2003/09/05] standards/56476standards cd9660 unicode support simple hack o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname p [2003/12/26] standards/60597standards FreeBSD's /usr/include lacks of cpio.h s [2004/02/14] standards/62858standards malloc(0) not C99 compliant p [2004/02/21] standards/63173standards Patch to add getopt_long_only(3) to libc o [2004/03/29] kern/64875 standards [patch] add a system call: fdatasync() o [2004/05/07] standards/66357standards make POSIX conformance problem ('sh -e' & o [2004/05/11] standards/66531standards _gettemp uses a far smaller set of filena o [2004/08/22] standards/70813standards [PATCH] ls not Posix compliant o [2004/08/26] docs/70985 standards [patch] sh(1): incomplete documentation o o [2004/09/22] standards/72006standards floating point formating in non-C locales o [2005/03/20] standards/79055standards Add an IFS regression test for shells o [2005/03/20] standards/79056standards regex(3) regression tests o [2005/03/21] standards/79067standards /bin/sh should be more intelligent about 32 problems total. 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 From owner-freebsd-standards@FreeBSD.ORG Thu Mar 31 05:31:00 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 CBAB916A4CE; Thu, 31 Mar 2005 05:31:00 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id A551943D3F; Thu, 31 Mar 2005 05:30:59 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j2V5UuA6027957; Thu, 31 Mar 2005 15:30:56 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j2V5UoMq003056; Thu, 31 Mar 2005 15:30:51 +1000 Date: Thu, 31 Mar 2005 15:30:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Tom Rhodes In-Reply-To: <20050330181904.16519571@mobile.pittgoth.com> Message-ID: <20050331144552.L20243@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: standards@freebsd.org Subject: Re: 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: Thu, 31 Mar 2005 05:31:00 -0000 On Wed, 30 Mar 2005, Tom Rhodes wrote: > Hi -standards. > > What do people think of the following patch to cp.c: It seems to be wrong. From cp(1): %%% COMPATIBILITY Historic versions of the cp utility had a -r option. This implementation supports that option, however, its use is strongly discouraged, as it does not correctly copy special files, symbolic links or fifo's. %%% Any change to the semantics of -r would break applications that depend on its historical behaviour. Any change that doesn't change the man page would be more broken. This conforms to at least POSIX.1-200x-draft7: %%% 10284 OB cp -r [-H | -L | -P][-fip] source_file ... target 10326 * If the -r option was specified, the behavior is implementation-defined. 10430 OB -r Copy file hierarchies. The treatment of special files is implementation-defined. %%% The correct fix is to remove the -r option. Unfortunately, POSIX broke this. > 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; The patch has lots of tab lossage and collateral indentation lossage... > @@ -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; > - } POSIX.1-200x-draft7 only requires -{HLP} to work with -R. Their behaviour with -r is not explicitly mentioned. It is strange to show them in the synopsis with -r when they are errors when actually used with -r. However, I think they should cause an error when used with -r, since their use with -r is not supported. -r could be made to work the same as -R iff it is used together with at least one pf -{HLP}, but that would be wrong since it would undeprecate -r. > + ... and wrong whitespace gainage. > 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); This is the main (only?) place where -r gives useful behaviour that is significantly different from -R. With a bare -r, cp always follows symlinks, but with a bare -R, cp never follows symlinks. (The behaviour of cp -r on non-regular files is not useful.) > ... > So, why/what am I doing: > > My copy of SuSv3 states that -r is about to become obsolete; My copy of cp.1 says that it became obsolete in BSD before 4.4BSDLite1 :-). It was obsolete long before that too, since it was obolete in FreeBSD-1. cp.1 in FreeBSD-1 is dated July 30, 1991. The deprecation apparently rotted a bit between Net/2 and 4.4BSD -- cp.1 in FreeBSD doesn't mention -r at all. > 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. This is the documented behaviour. > 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. -r is historical. POSIX permits it to be implementation-defined to prevent breaking it. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Mar 31 12:09:38 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 1371516A4CE; Thu, 31 Mar 2005 12:09:38 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2F6E43D4C; Thu, 31 Mar 2005 12:09:37 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2VC9VGs011032; Thu, 31 Mar 2005 07:09:31 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2VC9PbF011031; Thu, 31 Mar 2005 07:09:25 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 31 Mar 2005 07:09:25 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050331120925.GA11004@VARK.MIT.EDU> Mail-Followup-To: Bruce Evans , Tom Rhodes , standards@FreeBSD.ORG References: <20050330181904.16519571@mobile.pittgoth.com> <20050331144552.L20243@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331144552.L20243@delplex.bde.org> cc: Tom Rhodes cc: standards@FreeBSD.ORG Subject: Re: 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: Thu, 31 Mar 2005 12:09:38 -0000 On Thu, Mar 31, 2005, Bruce Evans wrote: > On Wed, 30 Mar 2005, Tom Rhodes wrote: > > >Hi -standards. > > > >What do people think of the following patch to cp.c: > > It seems to be wrong. From cp(1): [...] I knew someone would object to this. ;-) I think the rationale for the change is that nobody relies on the old, unportable behavior of -r, but many people get burned by saying -r when they meant -R. So the real question is whether it's true that nobody relies on the old behavior... From owner-freebsd-standards@FreeBSD.ORG Thu Mar 31 20:19:38 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 01B1D16A4CE; Thu, 31 Mar 2005 20:19:38 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DAA543D53; Thu, 31 Mar 2005 20:19:37 +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 j2VKJPMp077589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Mar 2005 15:19:34 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Thu, 31 Mar 2005 15:19:08 -0500 From: Tom Rhodes To: Bruce Evans Message-ID: <20050331151908.498559bd@mobile.pittgoth.com> In-Reply-To: <20050331144552.L20243@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050331144552.L20243@delplex.bde.org> 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 cc: Tom Rhodes cc: standards@FreeBSD.org Subject: Re: 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: Thu, 31 Mar 2005 20:19:38 -0000 On Thu, 31 Mar 2005 15:30:44 +1000 (EST) Bruce Evans wrote: > On Wed, 30 Mar 2005, Tom Rhodes wrote: > > > Hi -standards. > > > > What do people think of the following patch to cp.c: > > It seems to be wrong. From cp(1): ``seems'' is the word I'm looking at. :) > > %%% > COMPATIBILITY > Historic versions of the cp utility had a -r option. This implementation > supports that option, however, its use is strongly discouraged, as it > does not correctly copy special files, symbolic links or fifo's. > %%% It hangs on copying certain files. i.e.: It just sits there waiting for some kind of input. On SunOS 5.9, I get the same behavior; however, on their platform it's because the open64() call will hang while waiting for input from the fifo. On our system, it ``just hangs'' in place of sleeping, until the process is killed. > > Any change to the semantics of -r would break applications that depend on > its historical behaviour. Any change that doesn't change the man page would > be more broken. What, it would actually copy special files now? That seems to be a good thing. > > This conforms to at least POSIX.1-200x-draft7: > > %%% > 10284 OB cp -r [-H | -L | -P][-fip] source_file ... target > 10326 * If the -r option was specified, the behavior is implementation-defined. > 10430 OB -r Copy file hierarchies. The treatment of special files is implementation-defined. > %%% Yes I know that -r is implementation-defined and I'm talking about making it work right without adding a bunch of new code. Why not just fix? Because POSIX warns that the -r option will be obsoleted in the next revision. > > The correct fix is to remove the -r option. Unfortunately, POSIX broke > this. I agree, but we need to keep it for reasons you specify. At least for the time being. > > > 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; > > The patch has lots of tab lossage and collateral indentation lossage... In the space below?? > > > @@ -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; > > - } > > POSIX.1-200x-draft7 only requires -{HLP} to work with -R. Their behaviour > with -r is not explicitly mentioned. It is strange to show them in > the synopsis with -r when they are errors when actually used with -r. > However, I think they should cause an error when used with -r, since > their use with -r is not supported. -r could be made to work the same > as -R iff it is used together with at least one pf -{HLP}, but that > would be wrong since it would undeprecate -r. Exactly. We can still ERR for -r. > > > + > > ... and wrong whitespace gainage. Yes sir. :) > > > 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); > > This is the main (only?) place where -r gives useful behaviour that is > significantly different from -R. With a bare -r, cp always follows > symlinks, but with a bare -R, cp never follows symlinks. (The behaviour > of cp -r on non-regular files is not useful.) The only? Users can still use -RH, the -r option was removed from usage() awhile ago. I'm just trying to make life easier on those who still may accidently use -r on special files, while removing some (unused?) code. > > > ... > > > So, why/what am I doing: > > > > My copy of SuSv3 states that -r is about to become obsolete; > > My copy of cp.1 says that it became obsolete in BSD before 4.4BSDLite1 :-). > It was obsolete long before that too, since it was obolete in FreeBSD-1. > cp.1 in FreeBSD-1 is dated July 30, 1991. The deprecation apparently > rotted a bit between Net/2 and 4.4BSD -- cp.1 in FreeBSD doesn't mention > -r at all. Other than in the compatibility section? :) > > > 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. > > This is the documented behaviour. No, this is not the documented behavior. If this was the truth, the documenation would say: ``The -r option has become obsolete and will hang while copying special files. In some cases, the directory or files will be copied, but the special files will be ignored.'' On SunOS, correct documentation would be: ``Use of the -r option on some special files will cause the open64() system call to sleep, waiting for system input. In other occasions, some files might not be properly copied.'' > > > 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. > > -r is historical. POSIX permits it to be implementation-defined > to prevent breaking it. And we won't be breaking it. We won't be bringing it back. We're only going to remove it's functionality and let it work as if to be -R. -- Tom Rhodes From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 10:43:10 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 DC1FB16A4CE; Fri, 1 Apr 2005 10:43:09 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id E56FC43D1F; Fri, 1 Apr 2005 10:43:08 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j31Ah7A6009799; Fri, 1 Apr 2005 20:43:07 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j31Ah2Mq004626; Fri, 1 Apr 2005 20:43:03 +1000 Date: Fri, 1 Apr 2005 20:43:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Tom Rhodes In-Reply-To: <20050331151908.498559bd@mobile.pittgoth.com> Message-ID: <20050401191850.Q24028@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050331151908.498559bd@mobile.pittgoth.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: standards@freebsd.org Subject: Re: 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: Fri, 01 Apr 2005 10:43:10 -0000 On Thu, 31 Mar 2005, Tom Rhodes wrote: > On Thu, 31 Mar 2005 15:30:44 +1000 (EST) > Bruce Evans wrote: > >> On Wed, 30 Mar 2005, Tom Rhodes wrote: >> >>> Hi -standards. >>> >>> What do people think of the following patch to cp.c: >> >> It seems to be wrong. From cp(1): > > ``seems'' is the word I'm looking at. :) ``seems to be'' was only my first impression. >> %%% >> COMPATIBILITY >> Historic versions of the cp utility had a -r option. This implementation >> supports that option, however, its use is strongly discouraged, as it >> does not correctly copy special files, symbolic links or fifo's. >> %%% > > It hangs on copying certain files. i.e.: It just sits there > waiting for some kind of input. This is as expected. Special files have very special behaviour, depending on the file. For symlinks and fifo's, the behaviour is not very special, but rarely what you want for a recursive cp. Symlinks are just followed, and operations on fifos may block somewhere, depending on whether other processes have the fifo open and on other details. > On SunOS 5.9, I get the same > behavior; however, on their platform it's because the open64() > call will hang while waiting for input from the fifo. FreeBSD is no different. open() of a fifo for reading hangs waiting for a writer unless there is already data in the fifo. > On our system, it ``just hangs'' in place of sleeping, until > the process is killed. This might be because you used truss to watch the process, and truss is broken. truss is broken for me -- doesn't show the hanging open until truss and its child is killed with a SIGINT. ktrace+kdump shows the hanging open correctly. >> Any change to the semantics of -r would break applications that depend on >> its historical behaviour. Any change that doesn't change the man page would >> be more broken. > > What, it would actually copy special files now? That seems to > be a good thing. No, it would be incompatible. >> This conforms to at least POSIX.1-200x-draft7: >> >> %%% >> 10284 OB cp -r [-H | -L | -P][-fip] source_file ... target >> 10326 * If the -r option was specified, the behavior is implementation-defined. >> 10430 OB -r Copy file hierarchies. The treatment of special files is implementation-defined. >> %%% > > Yes I know that -r is implementation-defined and I'm talking > about making it work right without adding a bunch of new code. > Why not just fix? Because POSIX warns that the -r option will > be obsoleted in the next revision. Because the implementation defines it to do what it always did, so the proposed fix is breakage. >> The correct fix is to remove the -r option. Unfortunately, POSIX broke >> this. > > I agree, but we need to keep it for reasons you specify. At > least for the time being. I think we don't need to keep it except for POSIX compatibility. >>> Index: cp.c >>> =================================================================== >>> RCS file: /home/ncvs/src/bin/cp/cp.c,v >>> retrieving revision 1.51 >>> @@ -135,7 +135,7 @@ >>> pflag = 1; >>> break; >>> case 'r': >>> - rflag = 1; >>> + Rflag = 1; >>> break; >>> case 'v': >>> vflag = 1; >> >> The patch has lots of tab lossage and collateral indentation lossage... > > In the space below?? > All over. All tabs are corrupted to spaces, and this is done inconsistently, giving identation errors like the 9-character indents for the old and new version of the changed line in the above. >>> @@ -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); >> >> This is the main (only?) place where -r gives useful behaviour that is >> significantly different from -R. With a bare -r, cp always follows >> symlinks, but with a bare -R, cp never follows symlinks. (The behaviour >> of cp -r on non-regular files is not useful.) > > The only? Users can still use -RH, the -r option was removed > from usage() awhile ago. I'm just trying to make life easier > on those who still may accidently use -r on special files, > while removing some (unused?) code. New programs just shouldn't use cp -r. Old programs that use cp -r shouldn't have its behaviour changed. >>> So, why/what am I doing: >>> >>> My copy of SuSv3 states that -r is about to become obsolete; >> >> My copy of cp.1 says that it became obsolete in BSD before 4.4BSDLite1 :-). >> It was obsolete long before that too, since it was obolete in FreeBSD-1. >> cp.1 in FreeBSD-1 is dated July 30, 1991. The deprecation apparently >> rotted a bit between Net/2 and 4.4BSD -- cp.1 in FreeBSD doesn't mention >> -r at all. > > Other than in the compatibility section? :) I meant that cp.1 in FreeBSD-1 doesn't mention -r at all. The bitrot is documenting -r in the compatibility section. Without that, we would be closer to removing -r completely. Hmm, it's instructive that -r is documented in the COMPATIBILTY section. >>> 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. >> >> This is the documented behaviour. > > No, this is not the documented behavior. If this was the truth, > the documenation would say: No, the documented behaviour is that the copy is done incorrectly. Giving more details would be like documenting undefined behaviour. > ``The -r option has become obsolete and will hang while copying > special files. In some cases, the directory or files will > be copied, but the special files will be ignored.'' These details are wrong. What happens depends on the file type and/or external influences. E.g.: - for disk files, the underlying disk is copied. You had better be copying only a subset of /dev, or copying to a non-local file system, since the system is very unlikely to be able to hold [several] copies of its own disks in its own disk file systems. (Note that the copies of the disk files will be regular files, so it is not impossible that they fit -- they may be sparesely allocated or otherwise compressed if the target file system does such things.) - for ttys, the copy will hang in open() or read(), depending on ... Nevertheless, it may eventually complete, depending on whether someone or something provides EOF or EIO at the other end of the tty. - ... Files will never be ignored because of their file type, but files may be skipped (with an error) because they cannot be accessed at all. ENXIO for open() of special files with no driver is probably the most common cause of this in RELENG_4, but devfs "fixed" this in -current. > On SunOS, correct documentation would be: > > ``Use of the -r option on some special files will cause the > open64() system call to sleep, waiting for system input. > In other occasions, some files might not be properly copied.'' This is not wrong, but it says less than the current FreeBSD manpage, since it uses the weasel word "some" and doesn't mention symbolic links or fifos (maybe it doesn't need to mention fifos because Sun's -r acts differently on them). I think the details are slightly more complicated than for FreeBSD. I think Sun uses open() in some cases; then it would be open() and not open64() that hangs... >>> 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. >> >> -r is historical. POSIX permits it to be implementation-defined >> to prevent breaking it. > > And we won't be breaking it. We won't be bringing it back. > We're only going to remove it's functionality and let it work > as if to be -R. Changing it is the same as breaking it, since its purpose is to be (backwards) compatible. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 15:04:41 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 CD9B016A4CE for ; Fri, 1 Apr 2005 15:04:41 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 436E843D6B for ; Fri, 1 Apr 2005 15:04:41 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IE900A5XWAHAB00@bgo1smout1.broadpark.no> for standards@freebsd.org; Fri, 01 Apr 2005 16:59:05 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IE9000HXWM8KU70@bgo1sminn1.broadpark.no> for standards@freebsd.org; Fri, 01 Apr 2005 17:06:08 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 8C121BF790; Fri, 01 Apr 2005 17:04:38 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 182289C5BA for ; Fri, 01 Apr 2005 17:04:36 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 0B05033C3E; Fri, 01 Apr 2005 17:04:36 +0200 (CEST) Date: Fri, 01 Apr 2005 17:04:35 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) To: standards@freebsd.org Message-id: <86br8yr118.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: Subject: offsetof 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: Fri, 01 Apr 2005 15:04:41 -0000 I noticed that our definition of offsetof (in ) is as follows: #define __offsetof(type, field) ((size_t)(&((type *)0)->field)) This definition is gratuitously unportable (it assumes that a null pointer is all-bits-zero). A better definition would be the following: #define __offsetof(type, field) \ ((size_t)((char *)&((type *)0)->field - (char *)(type *)0)) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 15:18:03 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 C5F4C16A4CE for ; Fri, 1 Apr 2005 15:18:03 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 308C343D39 for ; Fri, 1 Apr 2005 15:18:03 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id j31FHxaa084989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 1 Apr 2005 10:18:02 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id j31FHxTO084986; Fri, 1 Apr 2005 10:17:59 -0500 (EST) (envelope-from wollman) Date: Fri, 1 Apr 2005 10:17:59 -0500 (EST) From: Garrett Wollman Message-Id: <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> To: Bruce Evans In-Reply-To: <20050401191850.Q24028@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050331151908.498559bd@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: standards@freebsd.org Subject: Re: 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: Fri, 01 Apr 2005 15:18:03 -0000 < said: [cp -r] > I think we don't need to keep it except for POSIX compatibility. > New programs just shouldn't use cp -r. Old programs that use cp -r > shouldn't have its behaviour changed. I'm more concerned about humans. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 15:28:05 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 1EC9E16A4CE for ; Fri, 1 Apr 2005 15:28:05 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99C9F43D2D for ; Fri, 1 Apr 2005 15:28:04 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id j31FRraa085066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 1 Apr 2005 10:27:54 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id j31FRrB9085063; Fri, 1 Apr 2005 10:27:53 -0500 (EST) (envelope-from wollman) Date: Fri, 1 Apr 2005 10:27:53 -0500 (EST) From: Garrett Wollman Message-Id: <200504011527.j31FRrB9085063@khavrinen.lcs.mit.edu> To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-Reply-To: <86br8yr118.fsf@xps.des.no> References: <86br8yr118.fsf@xps.des.no> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: standards@freebsd.org Subject: offsetof 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: Fri, 01 Apr 2005 15:28:05 -0000 < I noticed that our definition of offsetof (in ) is as > follows: > #define __offsetof(type, field) ((size_t)(&((type *)0)->field)) > This definition is gratuitously unportable (it assumes that a null > pointer is all-bits-zero). offsetof() is not supposed to be portable; that's why C requires that the implementation define it. In any case, for any architecture that FreeBSD runs on, the null pointer will be all-bits-zero. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 15:50:33 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 E8EAB16A4CE for ; Fri, 1 Apr 2005 15:50:33 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FDE243D3F for ; Fri, 1 Apr 2005 15:50:33 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j31FoSA6030988; Sat, 2 Apr 2005 01:50:28 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j31FoQMq025649; Sat, 2 Apr 2005 01:50:27 +1000 Date: Sat, 2 Apr 2005 01:50:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86br8yr118.fsf@xps.des.no> Message-ID: <20050402012011.K24853@delplex.bde.org> References: <86br8yr118.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-137614039-1112370626=:24853" cc: standards@freebsd.org Subject: Re: offsetof 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: Fri, 01 Apr 2005 15:50:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-137614039-1112370626=:24853 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 1 Apr 2005, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > I noticed that our definition of offsetof (in ) is as > follows: > > #define __offsetof(type, field) ((size_t)(&((type *)0)->field)) > > This definition is gratuitously unportable (it assumes that a null > pointer is all-bits-zero). A better definition would be the > following: > > #define __offsetof(type, field) \ > ((size_t)((char *)&((type *)0)->field - (char *)(type *)0)) Both are unportable, so FreeBSD uses the simplest one. In fact, the second one is more unportable since it is more complicated. In both, we don't assume anything about the representation of the null pointer; we assume that the undefined behaviour for "&((type *)0)->field" gives a useful value. This value can be the unrelated to the representation of "(type *)0", so it can be useful even if "(type *)0" isn't all-bits-0. The first version assumes that the useful value is the final result after further conversions. The second version assumes that the undefined behaviour of subtracting a null pointer from the useful value gives another useful value that is final value after further conversions. To be ungratuitously unportable, the definition needs to be machine- and compiler-dependent. We don't need the complications for this yet. It would be mainly compiler-dependent. Sample definitions: gcc: same as FreeBSD except for spelling TenDRA: #pragma token PROC { STRUCT s, TYPE t, MEMBER t : s : m |\ TYPE s, MEMBER s : m } EXP const : size_t : offsetof # ansi.stddef.offs= etof Bruce --0-137614039-1112370626=:24853-- From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 16:16:50 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 8D69316A4CE for ; Fri, 1 Apr 2005 16:16:50 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F20D643D54 for ; Fri, 1 Apr 2005 16:16:49 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j31GGiHn031749; Sat, 2 Apr 2005 02:16:44 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j31GGgS5010033; Sat, 2 Apr 2005 02:16:43 +1000 Date: Sat, 2 Apr 2005 02:16:41 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Garrett Wollman In-Reply-To: <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> Message-ID: <20050402015901.K24966@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: standards@freebsd.org Subject: Re: 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: Fri, 01 Apr 2005 16:16:50 -0000 On Fri, 1 Apr 2005, Garrett Wollman wrote: > < said: > > [cp -r] >> I think we don't need to keep it except for POSIX compatibility. > >> New programs just shouldn't use cp -r. Old programs that use cp -r >> shouldn't have its behaviour changed. > > I'm more concerned about humans. Removing the option is best for humans. -r is the same as -R under Linux (linux_base_8), and it isn't even deprecated in cp --help at least, so it won't go away, and fingers will be trained to use it in preference to -R, for at least another 20 years. This reminds me that I rarely actually use cp -R, since it is too broken to use -- it snaps hard links, unlike Linux cp. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 17:22:33 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 A88DA16A4CE for ; Fri, 1 Apr 2005 17:22:33 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C81343D3F for ; Fri, 1 Apr 2005 17:22:33 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j31HMNxY023786; Fri, 1 Apr 2005 12:22:23 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j31HM7Gr023785; Fri, 1 Apr 2005 12:22:07 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 1 Apr 2005 12:22:07 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050401172207.GA23665@VARK.MIT.EDU> Mail-Followup-To: Bruce Evans , Garrett Wollman , standards@FreeBSD.ORG References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> <20050402015901.K24966@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402015901.K24966@delplex.bde.org> cc: standards@FreeBSD.ORG Subject: Re: 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: Fri, 01 Apr 2005 17:22:33 -0000 On Sat, Apr 02, 2005, Bruce Evans wrote: > On Fri, 1 Apr 2005, Garrett Wollman wrote: > > >< > >said: > > > >[cp -r] > >>I think we don't need to keep it except for POSIX compatibility. > > > >>New programs just shouldn't use cp -r. Old programs that use cp -r > >>shouldn't have its behaviour changed. > > > >I'm more concerned about humans. [...] > -r is the same as -R under Linux (linux_base_8), and it isn't even > deprecated > in cp --help at least, so it won't go away, and fingers will be trained to > use it in preference to -R, for at least another 20 years. Isn't that an argument *for* Tom's patch? In any case, I think the argument about old programs is bogus, because there are undoubtedly more scripts that assume the Linux behavior than there are pre-4.2BSD scripts out there. Furthermore, are there situations where -r and -R differ such that -r would behave reasonably? If it's the case that every time someone uses -r they really mean -R, then simply eliminating -r is worse than making it an alias for -R. From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 17:37:31 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 290B516A4CE; Fri, 1 Apr 2005 17:37:31 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EE743D2D; Fri, 1 Apr 2005 17:37:30 +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 j31HbSMp085099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 12:37:29 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Fri, 1 Apr 2005 12:37:06 -0500 From: Tom Rhodes To: David Schultz Message-ID: <20050401123706.048e2ab6@mobile.pittgoth.com> In-Reply-To: <20050401172207.GA23665@VARK.MIT.EDU> References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> <20050402015901.K24966@delplex.bde.org> <20050401172207.GA23665@VARK.MIT.EDU> 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 cc: standards@FreeBSD.org Subject: Re: 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: Fri, 01 Apr 2005 17:37:31 -0000 On Fri, 1 Apr 2005 12:22:07 -0500 David Schultz wrote: > On Sat, Apr 02, 2005, Bruce Evans wrote: > > On Fri, 1 Apr 2005, Garrett Wollman wrote: > > > > >< > > >said: > > > > > >[cp -r] > > >>I think we don't need to keep it except for POSIX compatibility. > > > > > >>New programs just shouldn't use cp -r. Old programs that use cp -r > > >>shouldn't have its behaviour changed. > > > > > >I'm more concerned about humans. > [...] > > -r is the same as -R under Linux (linux_base_8), and it isn't even > > deprecated > > in cp --help at least, so it won't go away, and fingers will be trained to > > use it in preference to -R, for at least another 20 years. > > Isn't that an argument *for* Tom's patch? In any case, I think > the argument about old programs is bogus, because there are > undoubtedly more scripts that assume the Linux behavior than there > are pre-4.2BSD scripts out there. Yes, that is an argument for my patch. :) > > Furthermore, are there situations where -r and -R differ such that > -r would behave reasonably? If it's the case that every time > someone uses -r they really mean -R, then simply eliminating -r is > worse than making it an alias for -R. I agree that completely removing -r would be bad right now. -- Tom Rhodes From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 23:09:03 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 4C20716A4EC for ; Fri, 1 Apr 2005 23:09:03 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BA143D3F for ; Fri, 1 Apr 2005 23:09:02 +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 j31N8rMp086601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 18:09:00 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Fri, 1 Apr 2005 18:08:33 -0500 From: Tom Rhodes To: Bruce Evans Message-ID: <20050401180833.08b3b1fb@mobile.pittgoth.com> In-Reply-To: <20050402015901.K24966@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> <20050402015901.K24966@delplex.bde.org> 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 cc: standards@FreeBSD.org Subject: Re: 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: Fri, 01 Apr 2005 23:09:03 -0000 On Sat, 2 Apr 2005 02:16:41 +1000 (EST) Bruce Evans wrote: > On Fri, 1 Apr 2005, Garrett Wollman wrote: > > > < said: > > > > [cp -r] > >> I think we don't need to keep it except for POSIX compatibility. > > > >> New programs just shouldn't use cp -r. Old programs that use cp -r > >> shouldn't have its behaviour changed. > > > > I'm more concerned about humans. > > Removing the option is best for humans. > > -r is the same as -R under Linux (linux_base_8), and it isn't even deprecated > in cp --help at least, so it won't go away, and fingers will be trained to > use it in preference to -R, for at least another 20 years. > > This reminds me that I rarely actually use cp -R, since it is too broken > to use -- it snaps hard links, unlike Linux cp. Fix it. :) -- Tom Rhodes From owner-freebsd-standards@FreeBSD.ORG Fri Apr 1 23:58:15 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 9325616A4CE for ; Fri, 1 Apr 2005 23:58:15 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C8243D46 for ; Fri, 1 Apr 2005 23:58:14 +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 j31Nw3Mp086802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 18:58:13 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Fri, 1 Apr 2005 18:57:43 -0500 From: Tom Rhodes To: Bruce Evans Message-ID: <20050401185743.607471f9@mobile.pittgoth.com> In-Reply-To: <20050401191850.Q24028@delplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050331151908.498559bd@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> 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 cc: standards@FreeBSD.org Subject: Re: 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: Fri, 01 Apr 2005 23:58:15 -0000 On Fri, 1 Apr 2005 20:43:02 +1000 (EST) Bruce Evans wrote: > On Thu, 31 Mar 2005, Tom Rhodes wrote: > > > On Thu, 31 Mar 2005 15:30:44 +1000 (EST) > > Bruce Evans wrote: > > > >> On Wed, 30 Mar 2005, Tom Rhodes wrote: > >> > >>> Hi -standards. > >>> > >>> What do people think of the following patch to cp.c: > >> > >> It seems to be wrong. From cp(1): > > > > ``seems'' is the word I'm looking at. :) > > ``seems to be'' was only my first impression. See, I can play the game too. :) > > >> %%% > >> COMPATIBILITY > >> Historic versions of the cp utility had a -r option. This implementation > >> supports that option, however, its use is strongly discouraged, as it > >> does not correctly copy special files, symbolic links or fifo's. > >> %%% > > > > It hangs on copying certain files. i.e.: It just sits there > > waiting for some kind of input. > > This is as expected. Special files have very special behaviour, depending > on the file. For symlinks and fifo's, the behaviour is not very special, > but rarely what you want for a recursive cp. Symlinks are just followed, > and operations on fifos may block somewhere, depending on whether other > processes have the fifo open and on other details. Yes, I understand that, as discussed below: > > > On SunOS 5.9, I get the same > > behavior; however, on their platform it's because the open64() > > call will hang while waiting for input from the fifo. > > FreeBSD is no different. open() of a fifo for reading hangs waiting for > a writer unless there is already data in the fifo. > > > On our system, it ``just hangs'' in place of sleeping, until > > the process is killed. > > This might be because you used truss to watch the process, and truss is > broken. truss is broken for me -- doesn't show the hanging open until > truss and its child is killed with a SIGINT. ktrace+kdump shows the > hanging open correctly. Actually, I did use ktrace but probably didn't see the sleeping part. A mistake of mine. > > >> Any change to the semantics of -r would break applications that depend on > >> its historical behaviour. Any change that doesn't change the man page would > >> be more broken. > > > > What, it would actually copy special files now? That seems to > > be a good thing. > > No, it would be incompatible. How exactly. That is what I'm not getting. It will still do a recursive copy. Scripts using -r should still work as before. But how would this be any different from when POSIX does remove -r as planned? Would we wait for everyone else to catch up before removing the option? Or just leave it for another several years? > > >> This conforms to at least POSIX.1-200x-draft7: > >> > >> %%% > >> 10284 OB cp -r [-H | -L | -P][-fip] source_file ... target > >> 10326 * If the -r option was specified, the behavior is implementation-defined. > >> 10430 OB -r Copy file hierarchies. The treatment of special files is implementation-defined. > >> %%% > > > > Yes I know that -r is implementation-defined and I'm talking > > about making it work right without adding a bunch of new code. > > Why not just fix? Because POSIX warns that the -r option will > > be obsoleted in the next revision. > > Because the implementation defines it to do what it always did, > so the proposed fix is breakage. I'm also pointing out that in the version of POSIX I was reading has it marked to be obsoleted in the next version. (IEEE Std 1003.1-2001) > > >> The correct fix is to remove the -r option. Unfortunately, POSIX broke > >> this. > > > > I agree, but we need to keep it for reasons you specify. At > > least for the time being. > > I think we don't need to keep it except for POSIX compatibility. You're correct there. > > >>> Index: cp.c > >>> =================================================================== > >>> RCS file: /home/ncvs/src/bin/cp/cp.c,v > >>> retrieving revision 1.51 > >>> @@ -135,7 +135,7 @@ > >>> pflag = 1; > >>> break; > >>> case 'r': > >>> - rflag = 1; > >>> + Rflag = 1; > >>> break; > >>> case 'v': > >>> vflag = 1; > >> > >> The patch has lots of tab lossage and collateral indentation lossage... > > > > In the space below?? > > > > All over. All tabs are corrupted to spaces, and this is done > inconsistently, giving identation errors like the 9-character indents > for the old and new version of the changed line in the above. Probably a result of my ignorant editor. It did the same thing to poor Ruslan. :) > > >>> @@ -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); > >> > >> This is the main (only?) place where -r gives useful behaviour that is > >> significantly different from -R. With a bare -r, cp always follows > >> symlinks, but with a bare -R, cp never follows symlinks. (The behaviour > >> of cp -r on non-regular files is not useful.) > > > > The only? Users can still use -RH, the -r option was removed > > from usage() awhile ago. I'm just trying to make life easier > > on those who still may accidently use -r on special files, > > while removing some (unused?) code. > > New programs just shouldn't use cp -r. Old programs that use cp -r > shouldn't have its behaviour changed. Nothing would really change, per say. > > >>> So, why/what am I doing: > >>> > >>> My copy of SuSv3 states that -r is about to become obsolete; > >> > >> My copy of cp.1 says that it became obsolete in BSD before 4.4BSDLite1 :-). > >> It was obsolete long before that too, since it was obolete in FreeBSD-1. > >> cp.1 in FreeBSD-1 is dated July 30, 1991. The deprecation apparently > >> rotted a bit between Net/2 and 4.4BSD -- cp.1 in FreeBSD doesn't mention > >> -r at all. > > > > Other than in the compatibility section? :) > > I meant that cp.1 in FreeBSD-1 doesn't mention -r at all. The bitrot is > documenting -r in the compatibility section. Without that, we would be > closer to removing -r completely. Hmm, it's instructive that -r is > documented in the COMPATIBILTY section. Misworded, but there. :) > > >>> 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. > >> > >> This is the documented behaviour. > > > > No, this is not the documented behavior. If this was the truth, > > the documenation would say: > > No, the documented behaviour is that the copy is done incorrectly. > Giving more details would be like documenting undefined behaviour. Giving more details on what really happens is bad? I'd like to know that the process might be sleeping rather than seeming to have hung or perhaps copying forever. > > > ``The -r option has become obsolete and will hang while copying > > special files. In some cases, the directory or files will > > be copied, but the special files will be ignored.'' > > These details are wrong. What happens depends on the file type and/or > external influences. E.g.: > - for disk files, the underlying disk is copied. You had better be > copying only a subset of /dev, or copying to a non-local file system, > since the system is very unlikely to be able to hold [several] copies > of its own disks in its own disk file systems. (Note that the copies > of the disk files will be regular files, so it is not impossible that > they fit -- they may be sparesely allocated or otherwise compressed > if the target file system does such things.) > - for ttys, the copy will hang in open() or read(), depending on ... > Nevertheless, it may eventually complete, depending on whether someone > or something provides EOF or EIO at the other end of the tty. > - ... > Files will never be ignored because of their file type, but files may > be skipped (with an error) because they cannot be accessed at all. > ENXIO for open() of special files with no driver is probably the most > common cause of this in RELENG_4, but devfs "fixed" this in -current. I like how you quote fixed in the above comment. > > > On SunOS, correct documentation would be: > > > > ``Use of the -r option on some special files will cause the > > open64() system call to sleep, waiting for system input. > > In other occasions, some files might not be properly copied.'' > > This is not wrong, but it says less than the current FreeBSD manpage, > since it uses the weasel word "some" and doesn't mention symbolic links It was just something I threw together. Wasn't a committable version for the resons you specify. > or fifos (maybe it doesn't need to mention fifos because Sun's -r acts > differently on them). I think the details are slightly more complicated > than for FreeBSD. I think Sun uses open() in some cases; then it would > be open() and not open64() that hangs... Yes, it depends on the architecture whether open() or open64() will sleep. > > >>> 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. > >> > >> -r is historical. POSIX permits it to be implementation-defined > >> to prevent breaking it. > > > > And we won't be breaking it. We won't be bringing it back. > > We're only going to remove it's functionality and let it work > > as if to be -R. > > Changing it is the same as breaking it, since its purpose is to > be (backwards) compatible. In many ways, it will be. I've enjoyed this conversation but for such a small patch, I doubt the energy exists to continue much beyond another email or two. :( -- Tom Rhodes From owner-freebsd-standards@FreeBSD.ORG Sat Apr 2 07:46:17 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 1D11E16A4CE; Sat, 2 Apr 2005 07:46:17 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D3BC43D39; Sat, 2 Apr 2005 07:46:16 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j327kEA6032666; Sat, 2 Apr 2005 17:46:14 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j327kCS5003893; Sat, 2 Apr 2005 17:46:13 +1000 Date: Sat, 2 Apr 2005 17:46:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: David Schultz In-Reply-To: <20050401172207.GA23665@VARK.MIT.EDU> Message-ID: <20050402172651.T1084@epsplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> <20050401172207.GA23665@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: standards@FreeBSD.org Subject: Re: 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: Sat, 02 Apr 2005 07:46:17 -0000 On Fri, 1 Apr 2005, David Schultz wrote: > On Sat, Apr 02, 2005, Bruce Evans wrote: >> -r is the same as -R under Linux (linux_base_8), and it isn't even >> deprecated >> in cp --help at least, so it won't go away, and fingers will be trained to >> use it in preference to -R, for at least another 20 years. > > Isn't that an argument *for* Tom's patch? In any case, I think Of course not. It is an argument for removing -r. NetBSD hasn't changed the behaviour of -r. > the argument about old programs is bogus, because there are > undoubtedly more scripts that assume the Linux behavior than there > are pre-4.2BSD scripts out there. Probably not many running on BSD systems, since if they assume Linux semantics then they won't work except on directories and regular files. > Furthermore, are there situations where -r and -R differ such that > -r would behave reasonably? If it's the case that every time As I said, the main case where cp -r gives useful behaviour is for symlinks, where you actually want to follow symlinks but don't know about cp -RL. > someone uses -r they really mean -R, then simply eliminating -r is > worse than making it an alias for -R. No, it just forces them to use a portable flag. BTW, there are several utilities whose support for tree walks is deficient due to their only having a -r flag and not having caught up with the 13+ year old -RHLP flags. diff is the most important one. Bruce From owner-freebsd-standards@FreeBSD.ORG Sat Apr 2 08:10:10 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 44D5316A4CE; Sat, 2 Apr 2005 08:10:10 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C0743D2F; Sat, 2 Apr 2005 08:10:09 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j328A8A6004056; Sat, 2 Apr 2005 18:10:08 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j328A5S5007577; Sat, 2 Apr 2005 18:10:06 +1000 Date: Sat, 2 Apr 2005 18:10:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Tom Rhodes In-Reply-To: <20050401185743.607471f9@mobile.pittgoth.com> Message-ID: <20050402175234.C1084@epsplex.bde.org> References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <20050401185743.607471f9@mobile.pittgoth.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: standards@FreeBSD.org Subject: Re: 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: Sat, 02 Apr 2005 08:10:10 -0000 On Fri, 1 Apr 2005, Tom Rhodes wrote: > On Fri, 1 Apr 2005 20:43:02 +1000 (EST) > Bruce Evans wrote: > >> On Thu, 31 Mar 2005, Tom Rhodes wrote: >> >>> On Thu, 31 Mar 2005 15:30:44 +1000 (EST) >>> Bruce Evans wrote: >>>> Any change to the semantics of -r would break applications that depend on >>>> its historical behaviour. Any change that doesn't change the man page would >>>> be more broken. >>> >>> What, it would actually copy special files now? That seems to >>> be a good thing. >> >> No, it would be incompatible. > > How exactly. That is what I'm not getting. It will still do > a recursive copy. Scripts using -r should still work as before. No, they would start copying symlinks instead of following symlinks, and the might hang on special files, etc. > But how would this be any different from when POSIX does remove > -r as planned? Would we wait for everyone else to catch up > before removing the option? Or just leave it for another several > years? When -r is removed, anything that uses it will break, but if its behaviour is changed, anything that uses it may silently do the wrong thing. >>>>> 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. >>>> >>>> This is the documented behaviour. >>> >>> No, this is not the documented behavior. If this was the truth, >>> the documenation would say: >> >> No, the documented behaviour is that the copy is done incorrectly. >> Giving more details would be like documenting undefined behaviour. > > Giving more details on what really happens is bad? I'd like to > know that the process might be sleeping rather than seeming to > have hung or perhaps copying forever. Yes, generally giving too many implementation details is bad, because it restricts the implementation by forcing it to implement those details "forever". This is not so bad if implementation details are clearly marked as such. >>>> -r is historical. POSIX permits it to be implementation-defined >>>> to prevent breaking it. >>> >>> And we won't be breaking it. We won't be bringing it back. >>> We're only going to remove it's functionality and let it work >>> as if to be -R. >> >> Changing it is the same as breaking it, since its purpose is to >> be (backwards) compatible. > > In many ways, it will be. I've enjoyed this conversation but > for such a small patch, I doubt the energy exists to continue > much beyond another email or two. :( Here are some more quotes from POSIX.1-200x-draft7: %%% 10486 APPLICATION USAGE 10487 The difference between -R and -r is in the treatment by cp of file types other than regular and 10488 directory. The original -r flag, for historic reasons, does not handle special files any differently 10489 from regular files, but always reads the file and copies its contents. This has obvious problems in 10490 the presence of special file types; for example, character devices, FIFOs, and sockets. The -R 10491 option is intended to recreate the file hierarchy and the -r option supports historical practice. It 10492 was anticipated that a future version of this volume of IEEE Std 1003.1-200x would deprecate 10493 the -r option, and for that reason, there has been no attempt to fix its behavior with respect to 10494 FIFOs or other file types where copying the file is clearly wrong. However, some 10495 implementations support -r with the same abilities as the -R defined in this volume of 10496 IEEE Std 1003.1-200x. To accommodate them as well as systems that do not, the differences 10497 between -r and -R are implementation-defined. Implementations may make them identical. 10498 The -r option is now marked obsolescent. ... 10531 The -r option is historical practice on BSD and BSD-derived systems, copying file hierarchies as 10532 opposed to single files. This functionality is used heavily in historical applications, and its loss 10533 would significantly decrease consensus. The -R option was added as a close synonym to the -r 10534 option, selected for consistency with all other options in this volume of IEEE Std 1003.1-200x 10535 that do recursive directory descent. %%% POSIX introduced the -R flag because fixing the -r flag was too hard because the fixed version would be incompatible on thos systems that already had the -r flag (which are primarily BSD systems according to the rationale). Your change is only correct if: - fixing the -r flag is no longer too hard on FreeBSD systems, and - fixing it won't make untangling the flags harder. Bruce From owner-freebsd-standards@FreeBSD.ORG Sat Apr 2 10:08:00 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 9FB6016A4CE for ; Sat, 2 Apr 2005 10:08:00 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3957743D1F for ; Sat, 2 Apr 2005 10:08:00 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j32A7lis053484; Sat, 2 Apr 2005 05:07:47 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j32A7apu053483; Sat, 2 Apr 2005 05:07:36 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 2 Apr 2005 05:07:36 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050402100736.GA53369@VARK.MIT.EDU> Mail-Followup-To: Bruce Evans , Garrett Wollman , standards@FreeBSD.ORG References: <20050330181904.16519571@mobile.pittgoth.com> <20050401191850.Q24028@delplex.bde.org> <200504011517.j31FHxTO084986@khavrinen.lcs.mit.edu> <20050402015901.K24966@delplex.bde.org> <20050401172207.GA23665@VARK.MIT.EDU> <20050402172651.T1084@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050402172651.T1084@epsplex.bde.org> cc: standards@FreeBSD.ORG Subject: Re: 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: Sat, 02 Apr 2005 10:08:00 -0000 On Sat, Apr 02, 2005, Bruce Evans wrote: > On Fri, 1 Apr 2005, David Schultz wrote: > > >On Sat, Apr 02, 2005, Bruce Evans wrote: > >>-r is the same as -R under Linux (linux_base_8), and it isn't even > >>deprecated > >>in cp --help at least, so it won't go away, and fingers will be trained to > >>use it in preference to -R, for at least another 20 years. > > > >Isn't that an argument *for* Tom's patch? In any case, I think > > Of course not. It is an argument for removing -r. > > NetBSD hasn't changed the behaviour of -r. > > >the argument about old programs is bogus, because there are > >undoubtedly more scripts that assume the Linux behavior than there > >are pre-4.2BSD scripts out there. > > Probably not many running on BSD systems, since if they assume Linux > semantics then they won't work except on directories and regular files. > > >Furthermore, are there situations where -r and -R differ such that > >-r would behave reasonably? If it's the case that every time > > As I said, the main case where cp -r gives useful behaviour is for > symlinks, where you actually want to follow symlinks but don't know > about cp -RL. As (I think) Tom meant to suggest in his last message, -r could be made an alias for -RL. That would result in behavior less surprising than to most people than either -r's current behavior or removing -r entirely. Do you agree? > BTW, there are several utilities whose support for tree walks is deficient > due to their only having a -r flag and not having caught up with the 13+ > year old -RHLP flags. diff is the most important one. What I really want is a grep -R that understands how to skip special files. Actually, grep -R already exists, but it's just an alias for -r. You have to say 'grep -D skip -R', which I never remember until I've drummed my fingers on the keyboard for a while waiting for grep to finish. Actually, I think I'll go make an alias now... From owner-freebsd-standards@FreeBSD.ORG Sat Apr 2 17:22:45 2005 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3602E16A4CE; Sat, 2 Apr 2005 17:22:45 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C80F43D75; Sat, 2 Apr 2005 17:22:45 +0000 (GMT) (envelope-from stefanf@FreeBSD.org) Received: from freefall.freebsd.org (stefanf@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j32HMIdA096473; Sat, 2 Apr 2005 17:22:18 GMT (envelope-from stefanf@freefall.freebsd.org) Received: (from stefanf@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j32HMG6u096469; Sat, 2 Apr 2005 17:22:16 GMT (envelope-from stefanf) Date: Sat, 2 Apr 2005 17:22:16 GMT From: Stefan Farfeleder Message-Id: <200504021722.j32HMG6u096469@freefall.freebsd.org> To: chu@gpi.ru, stefanf@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/46504: Warnings in headers 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: Sat, 02 Apr 2005 17:22:45 -0000 Synopsis: Warnings in headers State-Changed-From-To: open->closed State-Changed-By: stefanf State-Changed-When: Sat Apr 2 17:20:46 GMT 2005 State-Changed-Why: Please update to >= 5.3, it has a newer GCC/libstdc++ where these warnings are fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=46504 From owner-freebsd-standards@FreeBSD.ORG Sat Apr 2 20:35:56 2005 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A99C116A4CE; Sat, 2 Apr 2005 20:35:56 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8099243D31; Sat, 2 Apr 2005 20:35:56 +0000 (GMT) (envelope-from das@FreeBSD.org) Received: from freefall.freebsd.org (das@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j32KZuS2024408; Sat, 2 Apr 2005 20:35:56 GMT (envelope-from das@freefall.freebsd.org) Received: (from das@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j32KZu97024404; Sat, 2 Apr 2005 20:35:56 GMT (envelope-from das) Date: Sat, 2 Apr 2005 20:35:56 GMT From: David Schultz Message-Id: <200504022035.j32KZu97024404@freefall.freebsd.org> To: fn@hungry.com, das@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/53613: FreeBSD doesn't define EPROTO 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: Sat, 02 Apr 2005 20:35:56 -0000 Synopsis: FreeBSD doesn't define EPROTO State-Changed-From-To: open->closed State-Changed-By: das State-Changed-When: Sat Apr 2 20:35:26 GMT 2005 State-Changed-Why: Fixed in 6-CURRENT, presently no plans to MFC. Thanks for reporting this! http://www.freebsd.org/cgi/query-pr.cgi?pr=53613