peter@sugar.uu.net (Peter da Silva) (11/16/88)
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.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (11/17/88)
: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. Er, no. The OS does not break it up or do wildcard expansion. The unix shell (CSH) does all of this and passes an argv list to exec[*](). The UNIX OS has no idea how to break up command lines and doesn't care. :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. If you use a CLI, no wildcard expansion is done. If you use a shell (hint hint), wildcard expansion IS done. :> I'd still have to vote for maintaining some way to support the argc/argv :> based programs... : :Me too. That makes 9 million! Me too. >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 If it could be 'standardized' for argc/argv programs and if we *remove* the other two ways to pass arguments. Right now there are three ways to pass arguments: (1) Pass char *ptr and length in registers to a program (2) Pass command line as part of the Input() filehandle to a program (3) Workbench Style #(1) is used by C programs, plus they usually go into the CLI structure to get the command name for argv[0], #(2) is used by BCPL programs and is limited to aprox, what, 202 char command lines? #(3) is used by workbench programs -Matt
peter@sugar.uu.net (Peter da Silva) (11/18/88)
In article <8811161827.AA28304@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: [Me: talking about calling programs] > :UNIX breaks the command line up into a bunch of argument strings (argv), does > :wildcard expansion, etc. > Er, no. The OS does not break it up or do wildcard expansion. The > unix shell (CSH) does all of this and passes an argv list to exec[*](). The > UNIX OS has no idea how to break up command lines and doesn't care. Well, OK. This is a bit of a nit. Besides, the UNIX shell is the Bourne shell. How about doing a 's/UNIX/UNIX shells (CSH or SH)/g' if it offends? > If you use a CLI, no wildcard expansion is done. If you use a > shell (hint hint), wildcard expansion IS done. The CLI is just a shell. The Workbench is just a shell. Your CSH-like shell is just a shell. Anyway... if you use the CLI then wildcard expansion may still be done... but by the program. If you use a UNIXy shell it will be done by the shell, but it might be truncated by the program. > >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. > If it could be 'standardized' for argc/argv programs and if we *remove* > the other two ways to pass arguments... Yes, wouldn't it be luvverly. And it can be done without Commodore being involved... all we need is a WB shell. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn business.