Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com!dana
From: dana@locus.com (Dana H. Myers)
Newsgroups: comp.os.misc
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <1991Jan16.222155.2836960@locus.com>
Date: 16 Jan 91 22:21:55 GMT
References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <1991Jan16.063253.2834681@locus.com> <1991Jan16.182106.1758@Think.COM>
Organization: Locus Computing Corporation, Inglewood, CA
Lines: 56

In article <1991Jan16.182106.1758@Think.COM> barmar@think.com (Barry Margolin) writes:
>In article <1991Jan16.063253.2834681@locus.com> dana@locus.com (Dana H. Myers) writes:
>>  Ok. Once you said "All tools should work together in a well
>>thought out way". Then you say that applications should be forced to
>>somehow tell the shell whether to glob or not. What this means is that
>>some applications would glob while others wouldn't. How would one know
>>what a given app does for sure? Hmmm..
>
>I'm getting tired of repeatedly seeing this argument.  How do you know that
>*any* program follows common conventions?  For instance, how would one know
>that a given app reads stdin and writes stdout, so that it can be used as a
>filter?  You know because someone once proclaimed this convention, and
>everyone simply follows it (except when they don't, such as in the "passwd"
>command, or curses applications, etc.).

 Well, if the shell always globs (or always doesn't glob), and the program
is not left to decide, then you always know how applications behave with
respect to globbing. In this case, the common convention is enforced by
the shell, which was the root of this entire discussion.

   The shell does not enforce any conventions on how a program deals
with I/O. This, as you point out, leads to ambiguity. I don't, however,
see how this speaks against my original argument (which you are tired
of seeing). My point is that enforcing conventions in one spot does
reduce the total 'ambiguity level' of the system, at the possible
expense of convenience or features.

>>  Also, how would you modify the way the shell works in order to
>>allow applications to control whether globbing is done on args? Please
>>keep in mind the way the shell works; it fork()s (that is, Jim, makes
>>another process which is a running copy of the shell) and then exec()s
>>the application (that is, replaces the running copy of the shell with
>>the application). At this point, the arguments have been processed
>>and the shell no longer has any control.
>
>There are lots of ways to do this.  The simplest way is for the shell not
>to glob, but for the application to call a library routine that does it.
>If you want the shell to glob before it invokes the application, it could
>maintain a database specifying the syntax of each command.  Or it could
>open the executable and read the argument syntax specification from the
>header before globbing.
>
>None of these changes are feasible in current Unix, but they are ideas for
>future OSes.

  One change which is feasible in current Unix is to use a permission
bit to specify glob/noglob (along with set-uid and the sticky bit). I would
argue this is the simplest; no change is required to the application (so
you get backward compatibility) and a minor change is required in the
shells. I don't seriously think this should be done, but it certainly
is feasible in the current context.

-- 
 * Dana H. Myers KK6JQ 		| Views expressed here are	*
 * (213) 337-5136 		| mine and do not necessarily	*
 * dana@locus.com		| reflect those of my employer	*