Path: utzoo!attcan!uunet!husc6!mailrus!ames!killer!texbell!tness1!sugar!peter
From: peter@sugar.uu.net (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: aliases and RUN
Message-ID: <2997@sugar.uu.net>
Date: 16 Nov 88 12:38:53 GMT
References: <5230@louie.udel.EDU> <483@boing.UUCP> <2975@sugar.uu.net> <3801@tekigm2.TEK.COM>
Organization: Sugar Land Unix - Houston, TX
Lines: 106

In article <3801@tekigm2.TEK.COM>, phils@tekigm2.TEK.COM (Philip E Staub) writes:
> >What overhead? You don't need to have Workbench loaded to start a task and send
> >it a workbench message. This is all documented in considerable detail in the
> But you'll still have to have WB up and running to be able to click on the
> CLI icon to spawn the program in the first place. 

Why? If I'm just running WBoid tasks I don't need the workbench. I'll have
a command line interface that operates like the UNIX shell, spawning off new
processes and waiting for them. It just won't have anything to do with CLI.
I have published two programs that do this (Browser and 'Click').
(This paragraph is exhibit C)

> >You're talking about the workbench *user* interface. I'm talking about the
> >workbench *programmer* interface. See exhibit B.
> Actually, my comment refers to both. I'm a little concerned that we are 
> losing sight of the fact that the Programmer is a user too, and although his
> needs may not be those of the majority of users, I hope they are still 
> worthy of consideration. [list of problems that dropping any command line
  interface would entail]

That's true, but see exhibit C.

> the message-passing mechanism for starting a Workbench based application may
> be clean and consistent and nice, but it also totally alien to any other C
> language programming environment I know about, at least insofar as command
> line arguments are concerned.

Actually, it's closer to UNIX than the CLI is.

The CLI passes the program a command line and expects the program to break it
up into filenames and arguments. This is perfect PC-ware behaviour.

UNIX breaks the command line up into a bunch of argument strings (argv), does
wildcard expansion, etc.

The Workbench passes a list of filenames and directory locks.

A well-behaved Amiga application cannot depend on the standard _main() code
breaking up the command line correctly. To begin with, it does no wildcard
expansion. Different versions of _main() handle quoted strings differently:
some use the UNIX convention, some use a subset, and others stick to the
CLI's overloading of '*' as the quote character.

The differences between WBArgs and Argv are definitely there, but they can be
addressed by a workbench-environment command-line shell. The code for doing
this is published (see "click", in comp.sources.amiga).

> I'd still have to vote for maintaining some way to support the argc/argv 
> based programs...

Me too.

  [agree that the CLI parsing is sticky, but...]
> But I'd have to think it would look just as bad to synthesize
> argc/argv from a Workbench startup message.

	char argbuffer[MAXARGV*MAXFILENAME];
	int argindex;
	char *argv[MAXARGV];
	int argc;

	struct WBStartup *wbstartup;
	int	wbindex;

	if(wbstartup->sm_NumArgs >= MAXARGV)
		wbstartup->sm_NumArgs = MAXARGV - 1;

	/* Copy arguments from wbstartup->sm_ArgList to argv, handling real
	   workbench arguments by calling _exp_path to convert the directory
	   lock into a path name. */
	for(wbindex = 0; wbindex < wbstartup->sm_NumArgs; wbindex++)
	{
		/* handle the easy case first */
		if(wbstartup->sm_ArgList[wbindex].wa_Lock == 0)
		{
			argv[argc++] = wbstartup->sm_ArgList[wbindex].wa_Name;
		}
		else /* grab another portion of buffer and fill it in */
		{
			argv[argc++] = &argbuffer[argindex];
			_exp_path(wbstartup->sm_ArgList[wbindex].wa_Lock,
				wbstartup->sm_ArgList[wbindex].wa_Name,
				&argbuffer[argindex]);
			argindex += strlen(argbuffer[argindex]) + 1;
		}
	}
	argv[argc] = 0;

	exit(main(argv, argc));

Where _exp_path is left as an excersise for the reader... basically you
backtrace the directory lock with ParentDir. This would look good in _main
in current implementations anyway, by the way...

> If the Workbench were the default
> environment when the system boots, you would have to start a CLI from
> Workbench, as is now possible, but which I seldom do, because I don't
> usually load Workbench as part of my startup-sequence.

As I envision it, this wouldn't be a problem because the default environment
would be a shell that uses the workbench model to spawn tasks.
-- 
		    Peter da Silva  `-_-'  peter@sugar.uu.net
		     Have you hugged  U  your wolf today?

	      Disclaimer: My typos are my own damn business.