Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.UUCP
Newsgroups: net.unix-wizards
Subject: Re: so who has mkdir and rmdir for non-4.2 systems
Message-ID: <5060@sun.uucp>
Date: Sat, 12-Jul-86 22:54:11 EDT
Article-I.D.: sun.5060
Posted: Sat Jul 12 22:54:11 1986
Date-Received: Sun, 13-Jul-86 10:19:00 EDT
References: <1885@brl-smoke.ARPA> <6179@elsie.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 62

> In article <1885@brl-smoke.ARPA>, gwyn@BRL.ARPA (VLD/VMB) writes:
> > < fragment of "mkdir" using "system">
> 
> The above can use a bit of idiot proofing--especially against meta
> characters in dirname.  Below is the version of "mkdir" that went out with
> the time zone stuff.
>
> <version of "mkdir", still using "system">

Well:

	1) the second version of "mkdir" should declare the path name
	   argument to "mkdir" as "register", since it's used enough
	   that it will make a difference.

	2) This applies to most non-4.2 systems, not just System V,
	   since they don't have "mkdir" or "rmdir" system calls either.
	   (It also *doesn't* apply to System V Release 3, since S5R3
	   *does* have "mkdir" and "rmdir".)

	3) Those non-4.2 systems have "fork" and the "exec" family of
	   routines.  Why not use them?  That keeps the shell out of
	   the path entirely, which means a) you don't have to worry
	   about what it does to metacharacters and b) it runs a bit faster.
	   You can use "execvp", which will do a path search for "mkdir",
	   and will even run it if it's a shell script.  On the other hand,
	   you can assume that it's in "/bin" or "/usr/bin", and that it's
	   an executable image, since both of those are true on any UNIX
	   system.

	4) If you really want to get fussy, you can worry about
	   figuring out *why* "mkdir" or "rmdir" fails, if it does, and
	   setting the error code in a 4.2BSD-compatible fashion.

	   You can also set it in a P1003-compatible fashion, but you probably
	   don't want to; there is only one place where P1003's and 4.2BSD's
	   error codes conflict, and P1003 is wrong and 4.2BSD is right in
	   that case.

	   The case in question is when "rmdir" is called with a path name
	   referring to a non-empty directory; P1003 specifies that "errno"
	   should be set to EEXIST in this case, while 4.2BSD returns
	   ENOTEMPTY.  If a program calls the UNIX "perror" routine after
	   "rmdir" fails", EEXIST will cause the message "File exists" to be
	   printed, while ENOTEMPTY will cause "Directory not empty" to be
	   printed.  The most logical user response to the first message
	   would be "Of *course* it exists, that's why I'm trying to remove
	   it!" while the most logical user response to the second message
	   would be "Oops, I guess I have to empty the directory out first."
	   The latter response is better, since it will either cause the
	   user to empty the directory, thus permitting it to be removed,
	   or cause the user to realize that the directory contains useful
	   files and should not be removed.

	   Since the P1003 standard is a Trial-Use standard, I presume
	   that it would be possible to fix this problem; I think recent
	   Sun comments on the standard have included a mention of this
	   problem.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)