jwz@spice.cs.cmu.edu (Jamie Zawinski) (11/06/88)
The problem proposed is this: One aliases 'cp' to the 'copy' command. 'cp foo bar' works, but 'run cp foo bar' doesn't. Someone suggested that aliases be expanded before being passed to RUN, which would make this problem go away. Someone else said that this would make 'delete cp' expand into 'delete copy', which is wrong. Well, the solution is to do this expansion of the second word only if the first word is 'RUN'. 'RUN' is magic, there's no way around that. This is a non-issue in the UNIX world, because the designers realized that spawning a process was a magic thing. You do that by 'cp foo bar &' - an ampersand at the end of the line. Then there's no first-word second-word dichotomy. Another win of the unix way is that you can do things like ( command-1 ; command-2 )& and have two things happen in series in the background. It takes some serious contortions to do that on the Amiga. So this RUN/alias is just another CLI bogosity as far as I'm concerned. Any slightly gross hack like special-casing the word RUN is worth it, since you're dealing with a silly system any way. Oh yeah, an implementation of this should be careful to compare the first word to RUN after expanding the first word, because that way you can still do: alias cp copy ; alias r run r cp foo bar and have it work. We shall cleanse the world!! Jamie Zawinski (jwz@spice.cs.cmu.edu or sun!sunpitt!eti!jwz)
kvancamp@ardec.arpa (Ken Van Camp) (11/08/88)
>Someone else said that this would make 'delete cp' expand into 'delete copy', >which is wrong. Well, the solution is to do this expansion of the second word >only if the first word is 'RUN'. 'RUN' is magic, there's no way around that. > >This is a non-issue in the UNIX world, because the designers realized that >spawning a process was a magic thing. You do that by 'cp foo bar &' - an >ampersand at the end of the line. Then there's no first-word second-word >dichotomy. Your Unix analogy is not valid. Just because you can do the equivalent of a RUN in Unix without a separate command doesn't mean second-word alias expansion is a non-issue. What about the many other commands in Unix that are used to run other commands? Offhand, I can think of a few ('nohup', 'sh', and 'exec'), but there are several others. No, I can't agree with your arguments. Second words should NEVER be expanded; that goes against the definition of aliases. Making RUN a special case is a hack; what about people who prefer RUNBACK or whatever else they want to use to spawn processes? --Ken Van Camp ARPANET: kvancamp@ARDEC.ARPA -or- kvancamp@AC4.PICA.MIL BITNET: (use above through normal gateways, like UBVM.CC.BUFFALO.EDU) USENET: uunet!ardec.arpa!kvancamp@UUNET.UU.NET To the battle cry they raised their glasses: "RTFM: Ray Tracing For the Masses!"
andy@cbmvax.UUCP (Andy Finkel) (11/08/88)
In article <3496@pt.cs.cmu.edu> jwz@spice.cs.cmu.edu (Jamie Zawinski) writes: >Another win of the unix way is that you can do things like > ( command-1 ; command-2 )& >and have two things happen in series in the background. It takes some serious >contortions to do that on the Amiga. All it takes is adding a plus sign to the end of each line, ie run echo "hi there" + echo "all of these commands" + echo "are executing in the background" + wait 3 mins If you think of the + CR as being similiar to the ; you will be less confused. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dale@boing.UUCP (Dale Luck) (11/09/88)
In article <5230@louie.udel.EDU> kvancamp@ardec.arpa (Ken Van Camp) writes: > > >Someone else said that this would make 'delete cp' expand into 'delete copy', > >which is wrong. Well, the solution is to do this expansion of the second word > >only if the first word is 'RUN'. 'RUN' is magic, there's no way around that. > > > >This is a non-issue in the UNIX world, because the designers realized that > >spawning a process was a magic thing. You do that by 'cp foo bar &' - an > >ampersand at the end of the line. Then there's no first-word second-word > >dichotomy. >Your Unix analogy is not valid. Just because you can do the equivalent >of a RUN in Unix without a separate command doesn't mean second-word alias >expansion is a non-issue. I agree that the unix analogy is not valid but for different reasons. The unix shell starts commands but spawning a task. (Easily done) and 'requires no magic' (which is my argument). The shell than waits for the child to return before continuing. If the shell sees the '&' in the command line it just does not wait for the child to return but continues to process input. So running commands in the background on unix is a function of the shell/cli instead of a seperate spawn program. Which brings up what I believe is a flaw in the amigados cli. It should be spawing a new task whenever you run a command as well. This insures the new task getting a proper launch as well as the command that does run does not get a chance to screw the cli's task information. This is most apparent when you type a cntrl^C while a command is running that ignores cntrl^C. This sets the signal in the cli's task structure such that the next command I type inherits those signals and if it looks for cntrl^C it usually exits immediately. Another case, if you start a command that makes use of the ieee library and you happen to have a 68881 in your system the task switch/launch control saves and restores the context of the 68881 between task switches. Now that program exits, because the program was actually using the cli's task, the entire used state of the 68881 is now being saved and restored by processes the most likely don't care anymore. I think 'run' should be obsoleted for proper cli/shell support of multitasking on the amiga. >No, I can't agree with your arguments. Second words should NEVER be >expanded; that goes against the definition of aliases. Making RUN a special >case is a hack; what about people who prefer RUNBACK or whatever else they >want to use to spawn processes? I agree here, if the cli/shell did the proper thing in the first place with handling background tasks this would not be an issue. -- Dale Luck Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
john13@garfield.MUN.EDU (John Russell) (11/09/88)
In article <5230@louie.udel.EDU> kvancamp@ardec.arpa (Ken Van Camp) writes: >No, I can't agree with your arguments. Second words should NEVER be >expanded; Speaking of which, using Shell 2.07m I have some variables set to common directory prefixes such as sys:utilities, etc. run $util/zoo ... will work but $util/zoo ... will not. Is there a way to make the first word expand? Frequently I don't want to use run, eg. with diskcopy. John -- In the Globe and Mail a few days ago, there was an ad for "dehydrated water", complete with a price and an address to order it.
peter@sugar.uu.net (Peter da Silva) (11/09/88)
In article <483@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes:
[Rewrite the CLI...]
I'd say... dump the CLI completely. Switch to a workbench environment.
Now, you can still have shells and command line interpreters, but make them
spawn programs in a workbench environment.
How? Well, when you kick off a WB command, WBStartup->sm_Arglist[0].wa_Lock
contains the directory the executable was in when you kicked it off. Also,
WBStartup->sm_Arglist[0].wa_Name contains its name.
Well, let's say you made WBStartup->sm_Arglist[0] a special case:
wa_Lock == current directory.
wa_Name == command line with fully qualified command name.
What would this break?
New programs would still work correctly from the WB, since wa_Lock is a
reasonable definition of the current directory and wa_Name is the command
name when run from that directory. If sm_NumArgs is 1, then you can use
the command line (feed it to existing _main()). If it's >1, then you know
you're in a workbench-only environment and you parse sm_Arglist normally.
Existing WB programs can still be executed by just typing in their name. The
wa_Lock will be wrong, but since wa_Name is a full path name they'll still
be able to open their .info file.
Existing CLI-only programs will crash. This is the biggy. Anyone have any
ideas?
There's no easy way to pass stdin, stdout, stderr, and stdcmd. Anyone have
any ideas? Without breaking too many programs, please...
Maybe make sm_NumArgs==0 a special case indicating that sm_ArgList is an a
new format (current directory, standard locks, argv...?)?
What are the advantages? The big one, of course, is we can kiss struct
CommandLineInterface goodbye.
--
Peter da Silva `-_-' peter@sugar.uu.net
Have you hugged U your wolf today?
Disclaimer: My typos are my own damn business.phils@tekigm2.TEK.COM (Philip E Staub) (11/13/88)
In article <2975@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <483@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: > [Rewrite the CLI...] > >I'd say... dump the CLI completely. Switch to a workbench environment. > Why? I hope you're kidding about this one. One reason I bought an Amiga instead of a Mac is that with the Amiga the icon oriented user interface is optional for those applications where it is appropriate, while on the Mac it is not. >Now, you can still have shells and command line interpreters, but make them >spawn programs in a workbench environment. So now you have the overhead of Workbench even when all you wanted was a CLI to begin with. I suppose you could make the same statement about Workbench having to deal with CLI's overhead, but somehow I don't think thats quite the same story. > ... >New programs would still work correctly from the WB, since wa_Lock is a >reasonable definition of the current directory and wa_Name is the command >name when run from that directory. If sm_NumArgs is 1, then you can use >the command line (feed it to existing _main()). If it's >1, then you know >you're in a workbench-only environment and you parse sm_Arglist normally. > One of my biggest beefs about the WB environment is that it is too difficult to change options. In my book, the inability to pass switches conveniently to a program (or perhaps more pointedly, to *change* the switches you pass to a program) negates the benefits of the nice icon oriented environment. Having to call up a utility to alter the arguments you pass doesn't cut it. (Of course *the* biggest beef is the '.info' files). > >Existing WB programs can still be executed by just typing in their name. The >wa_Lock will be wrong, but since wa_Name is a full path name they'll still >be able to open their .info file. > >Existing CLI-only programs will crash. This is the biggy. Anyone have any >ideas? You bet its the biggy. > >There's no easy way to pass stdin, stdout, stderr, and stdcmd. Anyone have >any ideas? Without breaking too many programs, please... > >Maybe make sm_NumArgs==0 a special case indicating that sm_ArgList is an a >new format (current directory, standard locks, argv...?)? > >What are the advantages? The big one, of course, is we can kiss struct >CommandLineInterface goodbye. >-- > Peter da Silva `-_-' peter@sugar.uu.net > Have you hugged U your wolf today? > > Disclaimer: My typos are my own damn business. I guess my feeling is that when you build layered software, you start with the primitive layers and build higher levels of capability upon it. Not start with a high level capability and implement access to the primitive regions of the machine with kludges. Maybe I misunderstood your intent here, but this is exactly what I feel you would be doing by making CLI run under Workbench, rather than the other way around. Am I just dense, or what? Phil -- ------------------------------------------------------------------------------ Phil Staub Tektronix, Inc., Vancouver, Washington 98668 phils@tekigm2.MEN.TEK.COM
peter@sugar.uu.net (Peter da Silva) (11/14/88)
In article <3792@tekigm2.TEK.COM>, phils@tekigm2.TEK.COM (Philip E Staub) writes: > In article <2975@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >In article <483@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: > > [Rewrite the CLI...] > >I'd say... dump the CLI completely. Switch to a workbench environment. > Why? Because the CLI programmer interface is inadequately documented, buggy, and a royal pain to use if you want to try to follow the rules. Even worse, it's infested with BPTRs. (I'm going to refer to this in the future... call this paragpraph "exhibit A") > I hope you're kidding about this one. One reason I bought an Amiga instead > of a Mac is that with the Amiga the icon oriented user interface is > optional for those applications where it is appropriate, while on the Mac it > is not. I didn't say change the user interface, just the programmer interface. As I went on to say... > >Now, you can still have shells and command line interpreters, but make them > >spawn programs in a workbench environment. > So now you have the overhead of Workbench even when all you wanted was > a CLI to begin with. 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 manuals. It's a very clean environment. (This paragraph is my second global reference... call it "exhibit B") > I suppose you could make the same statement about > Workbench having to deal with CLI's overhead, but somehow I don't think > thats quite the same story. No, it's worse. See exhibit A. > One of my biggest beefs about the WB environment is that it is too difficult > to change options.... You're talking about the workbench *user* interface. I'm talking about the workbench *programmer* interface. See exhibit B. > Maybe I misunderstood your intent here, > but this is exactly what I feel you would be doing by making CLI run under > Workbench, rather than the other way around. Currently, neither runs under either. The Workbench and the CLI are two completely different and mutually exclusive run environments layered on top of a 'process' structure. In the CLI you run as part of the CLI process, and in the workbench you run as a seperate process... much as you do in UNIX. > Am I just dense, or what? No, you probably just haven't done much programming in this area of the system. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn business.
phils@tekigm2.TEK.COM (Philip E Staub) (11/15/88)
Note that followups have been redirected to .tech, where I believe this discussion belongs. In article <2993@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: ..multiple references deleted.. >> > [Rewrite the CLI...] >> >I'd say... dump the CLI completely. Switch to a workbench environment. >> Why? > >Because the CLI programmer interface is inadequately documented, buggy, and >a royal pain to use if you want to try to follow the rules. Even worse, it's >infested with BPTRs. (I'm going to refer to this in the future... call this >paragpraph "exhibit A") I'll grant you that the CLI programmer interface has problems, but isn't dumping CLI a little like throwing the baby out with the bath water? > >> I hope you're kidding about this one. One reason I bought an Amiga instead >> of a Mac is that with the Amiga the icon oriented user interface is >> optional for those applications where it is appropriate, while on the Mac it >> is not. > >I didn't say change the user interface, just the programmer interface. As I OK. Sorry, I just got a bit confused. (Perhaps understandable, since you just said to "Dump CLI". To me, that could mean either (or both). >went on to say... > >> >Now, you can still have shells and command line interpreters, but make them >> >spawn programs in a workbench environment. >> So now you have the overhead of Workbench even when all you wanted was >> a CLI to begin with. > >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. >manuals. It's a very clean environment. (This paragraph is my second global >reference... call it "exhibit B") > >> I suppose you could make the same statement about >> Workbench having to deal with CLI's overhead, but somehow I don't think >> thats quite the same story. > >No, it's worse. See exhibit A. > >> One of my biggest beefs about the WB environment is that it is too difficult >> to change options.... > >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. First of all, much of the code I use, write, or port (much of it from Unix) passes command line options via the argv array. The thought of having to call up Workbench's INFO menu selection every time I wanted to switch between 'make -f makefile.1' and 'make -f makefile.2' or 'cc -n foo.c' and 'cc foo.c' or having to have two separate icons to do this worries me. (No, I haven't forgotten what you said about the fact that you could spawn a shell from WB. I guess I'm just not sure how I feel about *having* to do it). Your (correct) assumption below that I haven't done much (actually any) software which is specifically intended to be invoked from Workbench is going to show here, but I'm under the impression that 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. Isn't that what we're really talking about here? I'm really not trying to be reactionary about this, but if that's so, I'd still have to vote for maintaining some way to support the argc/argv based programs, if for no other reason than the fact that the Amiga is not (yet?) enough of a standard software environment that we can afford to just write off (or at least make more difficult to port) a very large existing base of code. And yes, I have looked at the startup modules which create the argc and argv which get passed to a user's 'main'. I know they aren't pretty. And I know that it is there mostly because of the ideosyncracies of the BCPL. But I'd have to think it would look just as bad to synthesize argc/argv from a Workbench startup message. > >> Maybe I misunderstood your intent here, >> but this is exactly what I feel you would be doing by making CLI run under >> Workbench, rather than the other way around. > >Currently, neither runs under either. The Workbench and the CLI are two >completely different and mutually exclusive run environments layered on top >of a 'process' structure. In the CLI you run as part of the CLI process, >and in the workbench you run as a seperate process... much as you do in UNIX. Perhaps I should have worded that a little differently. What I meant to say is that as things are now, the Workbench is started from the CLI environment that exists when the system boots. 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. > >> Am I just dense, or what? > >No, you probably just haven't done much programming in this area of the system. Yes, you are very correct here. >-- > Peter da Silva `-_-' peter@sugar.uu.net > Have you hugged U your wolf today? > > Disclaimer: My typos are my own damn business. Phil -- ------------------------------------------------------------------------------ Phil Staub Tektronix, Inc., Vancouver, Washington 98668 phils@tekigm2.MEN.TEK.COM