From tim@robbins.dropbear.id.au  Thu Feb 21 20:35:00 2002
Return-Path: <tim@robbins.dropbear.id.au>
Received: from descent.robbins.dropbear.id.au (156.a.005.mel.iprimus.net.au [210.50.40.156])
	by hub.freebsd.org (Postfix) with ESMTP
	id 31D0B37B420; Thu, 21 Feb 2002 20:34:43 -0800 (PST)
Received: (from tim@localhost)
	by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g1M4XsV38018;
	Fri, 22 Feb 2002 15:33:54 +1100 (EST)
	(envelope-from tim)
Message-Id: <200202220433.g1M4XsV38018@descent.robbins.dropbear.id.au>
Date: Fri, 22 Feb 2002 15:33:54 +1100 (EST)
From: Tim Robbins <tim@robbins.dropbear.id.au>
Reply-To: Tim Robbins <tim@robbins.dropbear.id.au>
To: FreeBSD-gnats-submit@freebsd.org
Cc: freebsd-standards@freebsd.org
Subject: link and unlink are not SUSv2-compliant as the manpage states
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         35201
>Category:       bin
>Synopsis:       link and unlink are not SUSv2-compliant as the manpage states
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    tjr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 21 20:40:01 PST 2002
>Closed-Date:    Fri Jul 12 00:49:45 PDT 2002
>Last-Modified:  Fri Jul 12 00:49:45 PDT 2002
>Originator:     Tim Robbins
>Release:        FreeBSD 4.5-STABLE i386
>Organization:
>Environment:
System: FreeBSD descent.robbins.dropbear.id.au 4.5-STABLE FreeBSD 4.5-STABLE #4: Fri Feb 15 13:31:25 EST 2002 tim@descent.robbins.dropbear.id.au:/usr/obj/usr/src/sys/DESCENT i386


	
>Description:
The manual pages for link and unlink, which are 'part of' ln and rm,
and share the same manual pages, claim that these utilities are SUSV2
compliant. This is not the case.

From The Single UNIX Specification, Version 2, XBD, Utility Argument Syntax:
Guideline 10:
"The argument -- should be accepted as a delimiter indicating the end of
options. Any following arguments should be treated as operands, even if they
begin with the "-" character. The -- argument should not be used as an
option or as an operand. Applications calling any utility with a first
operand starting with - should usually specify --, as indicated by Guideline
10, to mark the end of the options ..."
"... the Guidelines are rules for the standard utilities that claim
conformance to them."

link and unlink, therefore, should accept the "--" delimiter.

Another problem is that when link's 2nd operand is a directory, it creates
a link in that directory to the file named by the 1st operand, which is
not correct. SUSV2 specifies that "link a b" is performs the equivalent of
the function call link(a, b). unlink has the same problem: SUSV2 specifies
it must call unlink() (which means it shouldn't treat whiteouts specially
or try to reset immutable/append flags).

>How-To-Repeat:
N/A
>Fix:

Correct the manual pages by deleting the claims of SUSV2 conformance, or
apply these patches that implement the correct behaviour.

Index: ln/ln.c
===================================================================
RCS file: /home/ncvs/src/bin/ln/ln.c,v
retrieving revision 1.23
diff -u -r1.23 ln.c
--- ln/ln.c	2002/02/02 06:44:35	1.23
+++ ln/ln.c	2002/02/22 04:00:47
@@ -85,11 +85,14 @@
 	else
 		++p;
 	if (strcmp(p, "link") == 0) {
-		if (argc == 3) {
-			linkf = link;
-			exit(linkit(argv[1], argv[2], 0));
-		} else
+		argv++, argc--;
+		if (argc > 0 && strncmp(*argv, "--", 2) == 0)
+			argv++, argc--;
+		if (argc != 2)
 			usage();
+		if (link(argv[0], argv[1]) != 0)
+			err(1, "%s to %s", argv[0], argv[1]);
+		exit(0);
 	}
 
 	while ((ch = getopt(argc, argv, "fhinsv")) != -1)


Index: rm/rm.c
===================================================================
RCS file: /home/ncvs/src/bin/rm/rm.c,v
retrieving revision 1.36
diff -u -r1.36 rm.c
--- rm/rm.c	2002/02/14 01:59:47	1.36
+++ rm/rm.c	2002/02/22 04:07:03
@@ -95,11 +95,14 @@
 	else
 		++p;
 	if (strcmp(p, "unlink") == 0) {
-		if (argc == 2) {
-			rm_file(&argv[1]);
-			exit(eval);
-		} else 
+		argv++, argc--;
+		if (argc > 0 && strncmp(*argv, "--", 2) == 0)
+			argv++, argc--;
+		if (argc != 1)
 			usage();
+		if (unlink(*argv) != 0)
+			err(1, "%s", *argv);
+		exit(0);
 	}
 
 	Pflag = rflag = 0;

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Tim Robbins <tim@robbins.dropbear.id.au>
Cc: <FreeBSD-gnats-submit@FreeBSD.ORG>,
	<freebsd-standards@FreeBSD.ORG>
Subject: Re: bin/35201: link and unlink are not SUSv2-compliant as the manpage
 states
Date: Fri, 22 Feb 2002 23:40:19 +1100 (EST)

 On Fri, 22 Feb 2002, Tim Robbins wrote:
 
 > >Description:
 > The manual pages for link and unlink, which are 'part of' ln and rm,
 > and share the same manual pages, claim that these utilities are SUSV2
 > compliant. This is not the case.
 >
 > >From The Single UNIX Specification, Version 2, XBD, Utility Argument Syntax:
 > Guideline 10:
 > "The argument -- should be accepted as a delimiter indicating the end of
 > options. Any following arguments should be treated as operands, even if they
 
 Can you quote POSIX.1-2001?  It is more authoritative, and almost as
 easy to find.
 
 > ...
 > link and unlink, therefore, should accept the "--" delimiter.
 
 The fix for this part should use getopt(3) instead of yet more home
 made arg parsing.  getopt(3) gives special semantics "--" automagically.
 I think they are the same as specified in the guidelines.  Otherwise,
 many other utilities would have this bug.
 
 Bruce
 

From: Tim Robbins <tim@robbins.dropbear.id.au>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG
Subject: Re: bin/35201: link and unlink are not SUSv2-compliant as the manpage states
Date: Sat, 23 Feb 2002 01:00:50 +1100

 On Fri, Feb 22, 2002 at 11:40:19PM +1100, Bruce Evans wrote:
 
 > On Fri, 22 Feb 2002, Tim Robbins wrote:
 > 
 > > >Description:
 > > The manual pages for link and unlink, which are 'part of' ln and rm,
 > > and share the same manual pages, claim that these utilities are SUSV2
 > > compliant. This is not the case.
 > >
 > > >From The Single UNIX Specification, Version 2, XBD, Utility Argument Syntax:
 > > Guideline 10:
 > > "The argument -- should be accepted as a delimiter indicating the end of
 > > options. Any following arguments should be treated as operands, even if they
 > 
 > Can you quote POSIX.1-2001?  It is more authoritative, and almost as
 > easy to find.
 
 IEEE Std 1003.1-2001, Base Definitions, Utility Conventions, Utility
 Argument Syntax:
 Guideline 10: 
 "The argument -- should be accepted as a delimiter indicating the end of
 options. Any following arguments should be treated as operands, even if
 they begin with the '-' character. The -- argument should not be used as
 an option or as an operand."
 
 "The utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001
 that claim conformance to these guidelines shall conform completely to
 these guidelines as if these guidelines contained the term "shall" instead
 of "should"..."
 
 P1003.2-1992 is almost word-for-word the same.
 
 > 
 > > ...
 > > link and unlink, therefore, should accept the "--" delimiter.
 > 
 > The fix for this part should use getopt(3) instead of yet more home
 > made arg parsing.  getopt(3) gives special semantics "--" automagically.
 > I think they are the same as specified in the guidelines.  Otherwise,
 > many other utilities would have this bug.
 
 Yes, getopt(3)'s handling of -- is the same as that specified by the
 guidelines.
 
 I've adjusted the patches to rm and ln to use getopt instead of doing it
 themselves. I was hesitant in doing that at first because it breaks
 "unlink -foo", but P1003.2-1992 says:
 "Applications calling any utility with a first operand starting with "-"
 should usually specify "--", as indicated by Guideline 10, to mark the
 end of the options.  This is true even if the Synopsis in this standard
 does not specify any options; implementations may provide options as
 extensions to this standard."
 ... and I'm not sure anyone really uses link/unlink, anyway.
 
 
 Index: rm/rm.c
 ===================================================================
 RCS file: /home/ncvs/src/bin/rm/rm.c,v
 retrieving revision 1.36
 diff -u -r1.36 rm.c
 --- rm/rm.c	2002/02/14 01:59:47	1.36
 +++ rm/rm.c	2002/02/22 13:46:57
 @@ -95,11 +95,15 @@
  	else
  		++p;
  	if (strcmp(p, "unlink") == 0) {
 -		if (argc == 2) {
 -			rm_file(&argv[1]);
 -			exit(eval);
 -		} else 
 +		if (getopt(argc, argv, "") != -1)
  			usage();
 +		argc -= optind;
 +		argv += optind;
 +		if (argc != 1)
 +			usage();
 +		if (unlink(*argv) != 0)
 +			err(1, "%s", *argv);
 +		exit(0);
  	}
  
  	Pflag = rflag = 0;
 
 
 Index: ln/ln.c
 ===================================================================
 RCS file: /home/ncvs/src/bin/ln/ln.c,v
 retrieving revision 1.23
 diff -u -r1.23 ln.c
 --- ln/ln.c	2002/02/02 06:44:35	1.23
 +++ ln/ln.c	2002/02/22 13:46:41
 @@ -85,11 +85,15 @@
  	else
  		++p;
  	if (strcmp(p, "link") == 0) {
 -		if (argc == 3) {
 -			linkf = link;
 -			exit(linkit(argv[1], argv[2], 0));
 -		} else
 +		if (getopt(argc, argv, "") != -1)
  			usage();
 +		argc -= optind;
 +		argv += optind;
 +		if (argc != 2)
 +			usage();
 +		if (link(argv[0], argv[1]) != 0)
 +			err(1, "%s to %s", argv[0], argv[1]);
 +		exit(0);
  	}
  
  	while ((ch = getopt(argc, argv, "fhinsv")) != -1)

From: Peter Pentchev <roam@ringlet.net>
To: Sheldon Hearn <sheldonh@starjuice.net>
Cc: Tim Robbins <tim@robbins.dropbear.id.au>,
	bug-followup@FreeBSD.org, freebsd-standards@FreeBSD.org
Subject: Re: bin/35201: link and unlink are not SUSv2-compliant as the manpage states
Date: Fri, 22 Feb 2002 16:22:14 +0200

 On Fri, Feb 22, 2002 at 04:20:12PM +0200, Sheldon Hearn wrote:
 > 
 > 
 > On Fri, 22 Feb 2002 16:18:52 +0200, Sheldon Hearn wrote:
 > 
 > > The whole point of these alternatives to ln/rm is that they have a
 > > simple, optionless interface.  :-(
 > 
 > Bleh, what an entirely useless response. :-)
 > 
 > I should have gone on to say...
 > 
 > However, standards conformance is probably important, even here.  If
 > scripts expect 'link -- foo bar' to work, and yet it breaks in FreeBSD,
 > that'll be bad.
 
 I agree with that; and IMHO, since these utilities are really *not*
 expected to do any options parsing, we should just accept Tim's
 original patches, even as they avoid getopt(3).
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 I've heard that this sentence is a rumor.
State-Changed-From-To: open->patched 
State-Changed-By: tjr 
State-Changed-When: Tue Jun 25 02:01:04 PDT 2002 
State-Changed-Why:  
Fixed in -current, I will MFC the change soon. 


Responsible-Changed-From-To: freebsd-bugs->tjr 
Responsible-Changed-By: tjr 
Responsible-Changed-When: Tue Jun 25 02:01:04 PDT 2002 
Responsible-Changed-Why:  
Fixed in -current, I will MFC the change soon. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35201 
State-Changed-From-To: patched->closed 
State-Changed-By: tjr 
State-Changed-When: Fri Jul 12 00:48:04 PDT 2002 
State-Changed-Why:  
Changes have been MFC'd. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35201 
>Unformatted:
