march@m.cs.uiuc.edu (08/02/89)
I have an idea to use GNU's Readline Library and History Library to make an
Amiga shell front-end which will allow one to edit the current command
line using either vi or emacs editing commands. This will also allow you to
search your command history rather effortlessly. I feel that any Shell,
be it Amiga or UNIX have the ability to edit a command line and search one's
command history and that these functions be configurable. I think that this is
a step in the right direction.
I am more familiar with UNIX that with AmigaDOS and exec and hence this might
seem like a relatively easy or difficult project ...
My question: How does one pass a command line to the shell and then have
the shell parse and execute it?
I have considered looking at Matt Dillon's C Shell however I really don't want
to be wasting my time. Does anyone in netland have a simple solution or
a suggestion as to where I should concentrate my time and effort. Or maybe
one of you would ask why I even want to undertake such a project. Comments
anyone ...
Please reply as and where (i.e., email or netnews) you see fit. Thank
you in advance.
Steve
===============================================================================
Steve March (H) 344-5303
Department of Computer Science, University of Illinois (W) 333-7408
march@cs.uiuc.edu
{uunet,convex,pur-ee}!uiucdcs!march
"Emotions are alien to me. I'm a scientist." -- Spock, "This Side of Paradise"
===============================================================================mcr@julie.UUCP (Michael Richardson) (08/05/89)
In message <42700020@m.cs.uiuc.edu> Steve March writes: >My question: How does one pass a command line to the shell and then have >the shell parse and execute it? Such a simple request! I can't answer it. I tried for weeks to figure out why the Manx fexecv() (kindly left out in my edition of the Manual. Identical to the exec() functions. Except that it returns. error code is available by calling wait(). Sort of neat.) wouldn't let me change pr_CIS to redirect stdin. I gave up and created something called Rogue Start based on Peter da Silva's launch code. While everyone else is comparing Unix and AmigaDOS philosophy, I think I will add my own: (dawning Titanium-alloy armour with internal oxygen rebreather, cold fusion power pack with an Elven Cloak to cover it all.) Unix is a real beast. Anyone who has seen the configuration of Sun's 386i or knows of the lovely fence jumping SVR3.2 386 people do understands this. Unix is, I'd guess, bigger and more complex now than Multics, the OS whose hatred inspired K&R. AmigaDOS, (or rather, Exec) is by contrast, quite a small efficient streamlined OS, which doesn't at this time support virtual memory. (Soon, right V.. Ooops I'm not supposed to mention that.) Pre-VM Unixes were quite similar in many ways. However, AmigaDOS proper, doesn't share one important thing in common with Unix. - Policy - Unix has no policy. Do what you like. If it turns you on to make all of /usr/bin executable by others, but not members of group staff (to which all users belong) then that is YOUR perogative. If you really despise /bin/sh, don't use it. (Whether one can realistically do that with the heavy use of scripts is debatable. However, not having a C compiler also means you can't compile any C programs. sh compilers do exist if you don't even want /bin/sh online) If you don't like using ^H for the erase character, (talk to rms) then you don't. AmigaDOS on the other hand, incorporates policy into every part of it --- starting with the BSTR (what strings longer than 255 characters? No, no will want to do that...) Oh what if the command line is longer that that? Oh, not to worry, we'll just make sure that there aren't any programs that can accept more than 1 or 5 or 10 arguments. What about wildcards? Okay. That'll solve the number of arguments problem! We put them in the command. Noone will need to pass more than one wildcard or more than one parameter! Now what happens when I want to invoke a process? I can Execute(cmd,fh_of_script_file_usually_null,stdout) it. What happens if cmd comes from my command line? Like in executecmd "echo Hi there" After MY startup code has dealt with the " what does cmd equal? "echo Hi there" right? Okay, now I pass this to Execute() right? So echo gets "hi" and "there" -- guess what it says? 4 points to anyone who said "Echo: Bad Positional Argument" (admitedly, this is Arp. I haven't checked the real 1.3 stuff.) Okay. So how do I do this? (I was going to quote code, but I'll shutup faster than that.) It turns out that I need to enclose each argument that I got in "" to avoid having it broken up when echo comes up. Now what about failure codes? (I leave that as excersize for the student. :-) Those with WShell please keep quite.) I once brought up the fact that the CLI (Shell, ArpShell, WShell) are not a user level process. They are part of AmigaDOS. They are NOT shells. I was told that no, they are. The interface between them and AmigaDOS just isn't well defined. But the whole point of having a DOS at all is so that the user can have it load and start running a program. How should they do that? With a program of course. Which is loaded because the user asked DOS to run it for them, which was loaded because.... (flame off) Now don't get me wrong. I _DO_ do like passing messages (usefull exceptions would be a good idea. More reliance on Semaphores would help. Also, a Forbid()/Permit() pair for exceptions that was used by CA= libraries would do the trick.) In fact I don't see a way that intuition like things can be done well with messages. In the end, Unix has to pass messages too. However, look at the work that XDR has to do to get things like NFS going. I also like user level file systems, and I understand that the BCPL interface is going. (I don't care if AmigaDOS is written in C or not. So long as the interface is.) -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
mcr@julie.UUCP (Michael Richardson) (08/05/89)
In message <42700020@m.cs.uiuc.edu> Steve March writes: >My question: How does one pass a command line to the shell and then have >the shell parse and execute it? Such a simple request! I can't answer it. I tried for weeks to figure out why the Manx fexecv() (kindly left out in my edition of the Manual. Identical to the exec() functions. Except that it returns. error code is available by calling wait(). Sort of neat.) wouldn't let me change pr_CIS to redirect stdin. I gave up and created something called Rogue Start based on Peter da Silva's launch code. While everyone else is comparing Unix and AmigaDOS philosophy, I think I will add my own: (dawning Titanium-alloy armour with internal oxygen rebreather, cold fusion power pack with an Elven Cloak to cover it all.) Unix is a real beast. Anyone who has seen the configuration of Sun's 386i or knows of the lovely fence jumping SVR3.2 386 people do understands this. Unix is, I'd guess, bigger and more complex now than Multics, the OS whose hatred inspired K&R. AmigaDOS, (or rather, Exec) is by contrast, quite a small efficient streamlined OS, which doesn't at this time support virtual memory. (Soon, right V.. Ooops I'm not supposed to mention that.) Pre-VM Unixes were quite similar in many ways. However, AmigaDOS proper, doesn't share one important thing in common with Unix. - Policy - Unix has no policy. Do what you like. If it turns you on to make all of /usr/bin executable by others, but not members of group staff (to which all users belong) then that is YOUR perogative. If you really despise /bin/sh, don't use it. (Whether one can realistically do that with the heavy use of scripts is debatable. However, not having a C compiler also means you can't compile any C programs. sh compilers do exist if you don't even want /bin/sh online) If you don't like using ^H for the erase character, (talk to rms) then you don't. AmigaDOS on the other hand, incorporates policy into every part of it --- starting with the BSTR (what strings longer than 255 characters? No, no will want to do that...) Oh what if the command line is longer that that? Oh, not to worry, we'll just make sure that there aren't any programs that can accept more than 1 or 5 or 10 arguments. What about wildcards? Okay. That'll solve the number of arguments problem! We put them in the command. Noone will need to pass more than one wildcard or more than one parameter! Now what happens when I want to invoke a process? I can Execute(cmd,fh_of_script_file_usually_null,stdout) it. What happens if cmd comes from my command line? Like in executecmd "echo Hi there" After MY startup code has dealt with the " what does cmd equal? "echo Hi there" right? Okay, now I pass this to Execute() right? So echo gets "hi" and "there" -- guess what it says? 4 points to anyone who said "Echo: Bad Positional Argument" (admitedly, this is Arp. I haven't checked the real 1.3 stuff.) Okay. So how do I do this? (I was going to quote code, but I'll shutup faster than that.) It turns out that I need to enclose each argument that I got in "" to avoid having it broken up when echo comes up. Now what about failure codes? (I leave that as excersize for the student. :-) Those with WShell please keep quite.) I once brought up the fact that the CLI (Shell, ArpShell, WShell) are not a user level process. They are part of AmigaDOS. They are NOT shells. I was told that no, they are. The interface between them and AmigaDOS just isn't well defined. But the whole point of having a DOS at all is so that the user can have it load and start running a program. How should they do that? With a program of course. Which is loaded because the user asked DOS to run it for them, which was loaded because.... (flame off) Now don't get me wrong. I _DO_ do like passing messages (usefull exceptions would be a good idea. More reliance on Semaphores would help. Also, a Forbid()/Permit() pair for exceptions that was used by CA= libraries would do the trick.) In fact I don't see a way that intuition like things can be done well with messages. In the end, Unix has to pass messages too. However, look at the work that XDR has to do to get things like NFS going. I also like user level file systems, and I understand that the BCPL interface is going. (I don't care if AmigaDOS is written in C or not. So long as the interface is.) I have considered looking at Matt Dillon's C Shell however I really don't want to be wasting my time. Does anyone in netland have a simple solution or a suggestion as to where I should concentrate my time and effort. Or maybe one of you would ask why I even want to undertake such a project. Comments anyone ... Please reply as and where (i.e., email or netnews) you see fit. Thank you in advance. Steve =============================================================================== Steve March (H) 344-5303 Department of Computer Science, University of Illinois (W) 333-7408 march@cs.uiuc.edu {uunet,convex,pur-ee}!uiucdcs!march "Emotions are alien to me. I'm a scientist." -- Spock, "This Side of Paradise" =============================================================================== -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
shadow@pawl.rpi.edu (Deven T. Corzine) (08/08/89)
On 5 Aug 89 01:20:53 GMT, mcr@julie.UUCP (Michael Richardson) said: [lots of stuff about "policy"] methinks you've confused "policy" with "restrictions"... :-) mcr> I once brought up the fact that the CLI (Shell, ArpShell, WShell) mcr> are not a user level process. They most certainly ARE user-level processes. mcr> They are part of AmigaDOS. They are NOT shells. I was told that mcr> no, they are. The interface between them and AmigaDOS just isn't mcr> well defined. AmigaDOS's CLI *IS* a shell. It is a very simple shell, but it is a shell. What makes it so bizarre is that all programs it runs are loaded by the CLI, and run synchronously in the same process as the CLI, as if it were a function call. [which, in effect, it is.] mcr> But the whole point of having a DOS at all is so that the user mcr> can have it load and start running a program. How should they do mcr> that? With a program of course. Which is loaded because the user mcr> asked DOS to run it for them, which was loaded because.... The CLI is a shell, a specific program which _uses_ AmigaDOS calls to load a program, and simply jumps to the loaded code to start running it. [when the program exits, the CLI regains control and cleans up.] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.