pwh@bradley.bradley.edu (Pete Hartman) (04/11/91)
a goofy idea hit me today.
I'm a relative novice, so if this seems REALLY dumb, please cut me
a bit of slack.
Are there any Unix shells that are forth based? Is there some really
obvious reason why this would be [impractical|silly|stupid]? Would anyone
be interested? I would think it would be interesting to do, and might
be faster than the typical "script" approach to developing unix tools....
--
-----
Pete Hartman Bradley University pwh@bradley.bradley.edu
This is a chain letter. Within the next 55 days you will receive
thirty-eleven hundred pounds of chains!wmb@ENG.SUN.COM (04/11/91)
> Are there any Unix shells that are forth based? Is there some really > obvious reason why this would be [impractical|silly|stupid]? Would anyone > be interested? I would think it would be interesting to do, and might > be faster than the typical "script" approach to developing unix tools.... This idea comes up from time to time. As far as I know, nobody has taken a serious stab at implementing it. I have made some steps in that direction, as I will describe later, but first let me list some reasons why it may not be the best thing to do: 1) The Unix shells are basically programming languages whose primitive data types are strings and patterns. Forth doesn't exactly excel in its string-handling capabilities. Another thing that "standard" Forth doesn't have is dynamic memory allocation, which is pretty necessary for a lot of the things that shells do (e.g. argument wildcard expansion). 2) The existing Unix shells are pretty adequate for the jobs that most people want to do with them. Sometimes the "quoting" in scripts gets a bit hairy, but by and large people can get the job done. 3) The value of many shell scripts is strongly related to the number of people who can or will use it. "fsh" scripts would have a pretty limited audience, since the job of propagating a new language to a wide audience is very very difficult (Proof: literally thousands of programming languages have been invented and implemented, but only a handful have more that 100 users, and the number of languages that are truly widespread is small indeed). 4) It would take many many hours of work to bring the functionality of an "fsh" up to the level of ksh or the latest version of csh. What would be the payoff? Here's what I have done already (and I doubt that I will do much more along these lines): a) You can execute Unix shell commands from within Forth. The most popular commands can be execute directly, simply by typing their names. Other commands must be preceded by "sh ". I once had a mode whereby any unrecognized word was sent to a subshell for execution, but I decided that I didn't like that behavior and turned it off. b) My Forth system has a line editor with interactive history and command completion. This can be used for shell commands too. Before ksh came out, I used to use Forth as a front end to csh just so I could have the editing functions, but now that we have ksh, I just use it directly. c) On non-Unix machines, I do use Forth as a shell. The Atari ST and the Macintosh do not come with a standard shell program, so I use Forth as a shell when I don't want to use their graphical user interface. The standard OS-9 shell is pretty wimpy (the line editing functions are weak), so I use Forth as an editing front end for it. Mitch Bradley, wmb@Eng.Sun.COM
bouma@cs.purdue.EDU (William J. Bouma) (04/12/91)
In article <1991Apr10.233447.2614@bradley.bradley.edu> pwh@bradley.bradley.edu (Pete Hartman) writes: >Are there any Unix shells that are forth based? Is there some really >obvious reason why this would be [impractical|silly|stupid]? Would anyone >be interested? I would think it would be interesting to do, and might >be faster than the typical "script" approach to developing unix tools.... Well, if it is "stupid", call me an idiot! 8^) It is difficult to mesh Forth and Unix together cleanly. For example, it would be nice to use RPN for the Unix commands, but how can you do it without being messy? It should be possible to pipe from unix commands into Forth words. How would you do that? Where do you get arguments for "aliased" unix commands and how do you specify them? What I am trying to say is that to do this right, unix commands should be indistinguishable from Forth words. There should be no special syntax involved. Tell me how to do this, and I will send you fsh. I think if you try doing it, after a while you'll notice you no longer have the same Forth that everyone else in this group has. In fact it will be difficult to convince some of them that what you have even is Forth. ;^) PS (yeah!) I like the way you think Mr. Hartman. -- Bill <bouma@cs.purdue.edu>
bouma@cs.purdue.EDU (William J. Bouma) (04/13/91)
In article <9104121340.AA17242@ucbvax.Berkeley.EDU> wmb%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: > > 3) The value of many shell scripts is strongly related to the number > of people who can or will use it. "fsh" scripts would have a > pretty limited audience, since the job of propagating a new > language to a wide audience is very very difficult (Proof: > ... and the number of languages that are truly widespread is small > indeed). > > 4) It would take many many hours of work to bring the functionality > of an "fsh" up to the level of ksh or the latest version of csh. > What would be the payoff? 'sh' was "adequate" but someone bothered to write 'csh'. 'csh' was adequate, but someone wrote 'ksh'. 'ksh' is good, but someone writes 'bash' anyway. I think there will always be a great need for a "better" shell. And just think what it would do for the "acceptance of Forth" that several in this group crave so badly. My payoff is to have a shell that makes complete sense. (and get fame maybe 8^) All shells I have seen are messy in some sense. There is weird non-intuitive syntax, and the commands you put into files aren't identical to the stuff you type in directly. I thought that a Forth based shell might be able to overcome these problems. But after thinking about it a great deal and even writing some code, I am no longer sure. Below are some excerpts from my ".fshrc" file just to give you a sense of simple fsh code looks like. I can mail anyone who is interested the brief (~800 lines) documentation for fsh as it now stands. It may be possible to talk me into sending the code if you seriously want to work on the program. As Mitch implies, writing a decent shell is nontrivial. On the other hand, it's fun! -- Bill <bouma@cs.purdue.edu> silent unix { "/bin" "." "/usr/local/bin" "/usr/ucb" "/usr/new/bin" "/usr/bin" "/usr/bouma/bin/sun" "/usr/local/gnu" "/usr/unsup/bin" "/usr/sbin" "/usr/local/X11R4" "/usr/bouma/bin/csh" "/usr/etc" } string vector PATH ! : #:o ibase @ 8 ibase ! text number swap ibase ! ; #o77 umask ! : hdcpy enscript -2Gr ; ' prompt:print forget ( to eliminate redefinition warning ) : prompt:print cwd . ; "/usr/local/tex/man:/usr/local/X11R4/man:/usr/local/X11R4/man/InterViews:/usr/local/pbm/man:/usr/local/gnu/man:/usr/man" setenv MANPATH forth : ls unix:ls -CF ; : la ls -a ; : ll ls -ls ; : words-in variable csave context @ csave ! read context ! words csave @ context ! ;