Date: Fri, 22 Feb 2002 06:10:01 -0800 (PST) From: Tim Robbins <tim@robbins.dropbear.id.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/35201: link and unlink are not SUSv2-compliant as the manpage states Message-ID: <200202221410.g1MEA1A91852@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/35201; it has been noted by GNATS.
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)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202221410.g1MEA1A91852>