remy@gem.stack.urc.tue.nl (Remy Wetzels) (03/08/91)
Hi all you netters,
This is a question which probably has been asked before,
WHAT'S THE BEST CLI ??????
I've got a harddisk attached to my ST now, so there was the need for
a good CLI... I'm using GULAM now for a while, it works very nice but
I miss the possibility to pipe (nroff man.1 | more doesn't work :-().
MiNT doesn't seem to work fine and CLEO or CMD are to simple to mention.
I WONNA HAVE A WORKING UNIX SHELL (DON'T TELL me to buy MINIX! or a
REAL machine (that's UNIX)). For the GEM-users: YES! Neodesk 3 seems to be
really nice, but as I mentioned before; I like piping | piping...
As a REAL programmer (read the article from McGee (1982)) I should
probably write my own CLI, but being a student of computer science in
Eindhoven where we are teached the EDSGER W. DIJKSTRA-principle of
structered programming (Yes! :-( He messed it together in Eindhoven)
is a hard time enough already...
Any comments are welcome to this newsgroup or my E-mail addres.
Greetings,
|-----------------------|
Remy Wetzels | Alias Remy Mindcrime |
| Alias ls -b Order Beer|
"The Criminal Mind found at the Scene of the Crime"| Alias rm -b Drink Beer|
" Handcuffed and Blind, I didn't do it... "| Alias ftp b Buy Beer |
| Alias Beer Brand Beer|
"I don't believe in Love"-Queensryche |-----------------------|
=============================================================================
Email: Internet: remy@gem.stack.urc.tue.nl Bitnet: rcstack1@heitue5
remy@amice1.stack.urc.tue.nl rcstack2@heitue5
remy@amice2.stack.urc.tue.nl
rcstack@urc.tue.nl
Computer Association STACK, Computing Centre RC 1.81,
Eindhoven University of Technology, POBox 513, 5600 MB Eindhoven, Holland.
7103_2622@uwovax.uwo.ca (Eric Smith) (03/09/91)
In article <170@gem.stack.urc.tue.nl>, remy@gem.stack.urc.tue.nl (Remy Wetzels) writes: > > WHAT'S THE BEST CLI ?????? ... > MiNT doesn't seem to work fine and CLEO or CMD are to simple to mention. Just to clarify: MiNT is not a CLI. There is a very simple (toy, really) shell that comes with MiNT as init.prg, but you're not stuck with that one. Try using bash or ksh under MiNT -- you may like them a lot better. (MiNT is just the kernel that the shells run under, that provides things like multitasking, pipes, pseudo-terminals, and job control). -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet
s37837k@saha.hut.fi (Jari Lehto) (03/11/91)
There is a very good CLI available for NeoDesk. This CLI accepts both Unix and MS-DOS type commands and it runs in it's own window on the desktop. I think you need NeoDesk to use it. Contact Gribnif Software for further information... (I think they are on line) *** Jari Lehto, jartsu@otax.hut.fi, s37837k@saha.hut.fi ***
wolfram@tschil.informatik.rwth-aachen.de (Wolfram Roesler) (03/12/91)
remy@gem.stack.urc.tue.nl (Remy Wetzels) writes: > WHAT'S THE BEST CLI ?????? >a good CLI... I'm using GULAM now for a while, it works very nice but >I miss the possibility to pipe (nroff man.1 | more doesn't work :-(). Right, Gulam isnt quite the best shell. It misses a lot more than only pipes. >I WONNA HAVE A WORKING UNIX SHELL Try the Okami Shell. It has (almost) all features of the Unix Bourne Shell, including I/O-Redirection (incl. pipes of course), shell functions and variables (of course), PATH and CDPATH and Environment and hashing and and and.... and more than 100 built-in commands for almost anything, including grep, more, basename and friends, df, du, shutdown,.... plus a lot of tools like terminal server and modem dialer and many, many more... Sorry I dont know if its available on the uucp net, keep your eyes open. The safest way to get a copy of it is to send a disk plus stamped return envelope to the adress below. By the way, its a public domain program, so its absolutely free (no share- ware or something.) The documentation contains a file comparing the Okami Shell to other shells like Gulam. The Okami Shell scored twice as much... So far for your question about the BEST shell. Other shells may have features that Okami has not (is doenst have a built-in Emacs), but all in all nobody can beat the Okami Shell regarding the amount of features it offers. BCingU Wolfram Roesler Augustastr. 44-46 D-5100 Aachen Germany
david@doe.utoronto.ca (David Megginson) (03/12/91)
Bash and ksh are Unix shells, so they have a user and support base many times larger than the ST could ever afford, and both of them run well under MiNT. Shells like gulam are not too nice, because they have all of the commands built-in. That's acceptable if you're running only one invocation of a shell, but if you have three shells open in three MGR windows, and a fourth running a script in the background, it's a ridiculous waste of valuable memory. Besides, it's nice to be able to run commands like rm(1) and cp(1) in the background instead of waiting for them to finish. I would not suggest using any shell which does not use MiNT, since it will not have multi-tasking (please, no more flames from people who can't tell multi-tasking, running many tasks, from multi-processing, using more than one processor) or true pipes (using temporary files just doesn't cut it). David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
Bill_von_Hagen@TRANSARC.COM (03/13/91)
I would strongly advocate the Beckemeyer Multi-tasking C-shell. It really
works like the standard C-shell, comes with a wide selection of Un*x
utilities, and isn't very expensive. A graphical manager for multiple
Mt-Cshell sessions is also available, and works extremely well.
I have no connection with Beckemeyer, aside from being a long-term,
satisfied customer. I'll be happy to provide more info if anyone's
interested - send me mail directly to spare the bandwidth here.
Billboyd@nu.cs.fsu.edu (Mickey Boyd) (03/13/91)
In article <wolfram.668771933@tschil>, wolfram@tschil.informatik.rwth-aachen.de (Wolfram Roesler) writes: >remy@gem.stack.urc.tue.nl (Remy Wetzels) writes: > >> WHAT'S THE BEST CLI ?????? > >Try the Okami Shell. It has (almost) all features of the Unix Bourne Shell, >[....] >Sorry I dont know if its available on the uucp net, keep your eyes open. >The safest way to get a copy of it is to send a disk plus stamped return >envelope to the adress below. > > Wolfram Roesler > Augustastr. 44-46 > D-5100 Aachen > Germany Um, does anyone know how to figure out what postage to put on the SASE? Do the stamps have to be German? Could I just include $5 or something?!? -- ---------------------------------+------------------------------------- Mickey R. Boyd | "It's amazing how much growing up FSU Computer Science | resembles being too tired." Technical Support Group | email: boyd@fsucs.cs.fsu.edu | - Heinlein ---------------------------------+-------------------------------------
warwick@cs.uq.oz.au (Warwick Allison) (03/13/91)
In <1991Mar12.144653.11654@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: >Bash and ksh are Unix shells, so they have a user and support base many >times larger than the ST could ever afford, and both of them run well >under MiNT. Shells like gulam are not too nice, because they have all >of the commands built-in. That's acceptable if you're running only one >invocation of a shell, but if you have three shells open in three MGR >windows, and a fourth running a script in the background, it's a ridiculous >waste of valuable memory. Sounds like a TSR is necessary - so instruction space can be shared. Has anyobdy done any work on this idea? -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
rome@ucscb.UCSC.EDU (60380000) (03/13/91)
In article <wolfram.668771933@tschil> wolfram@tschil.informatik.rwth-aachen.de (Wolfram Roesler) writes: >Try the Okami Shell. It has (almost) all features of the Unix Bourne Shell, >including I/O-Redirection (incl. pipes of course), shell functions and >variables (of course), PATH and CDPATH and Environment and hashing and and >and.... and more than 100 built-in commands for almost anything, including >grep, more, basename and friends, df, du, shutdown,.... plus a lot of tools >like terminal server and modem dialer and many, many more... >Sorry I dont know if its available on the uucp net, keep your eyes open. >By the way, its a public domain program, so its absolutely free (no share- >ware or something.) >ware or something.) Does anyone out there have this shell? I really like Gulam but it just hates to work with MiNT. The problem with the other shels is that all of the commands are external programs. This Okami Shell sounds great if anyone has it, I (and probably other people) would appreaciate it if it was available on the net. Thanks Roman Baker University of California, Santa Cruz
david@doe.utoronto.ca (David Megginson) (03/13/91)
In <111@uqcspe.cs.uq.oz.au>, warwick@cs.uq.oz.au writes: > > Sounds like a TSR is necessary - so instruction space can be shared. > Has anyobdy done any work on this idea? > Eric Smith plans to add shared text segments to a later version of MiNT. I am not sure exactly what this involves, but I imagine that he will come up with some way of identifying a program which is already running (same path and checksum?), and swap the .bss and .data in and out with task changes. This would slow down MiNT a bit, but with programs like bash(1) which is mostly .text, it would save a lot of memory. Comments? Suggestions? If someone wants to write this themselves, it will show up faster (Eric shouldn't have to do everything himself). David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
bammi@acae127.cadence.com (Jwahar R. Bammi) (03/14/91)
In article <111@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au (Warwick Allison) writes: > Sounds like a TSR is necessary - so instruction space can be shared. i hope you mean shared text segments. if not, please fedex me a barf bag :-) -- bang: uunet!cadence!bammi jwahar r. bammi domain: bammi@cadence.com GEnie: J.Bammi CIS: 71515,155
hyc@hanauma.jpl.nasa.gov (Howard Chu) (03/14/91)
In article <BAMMI.91Mar13145510@acae127.cadence.com> bammi@acae127.cadence.com (Jwahar R. Bammi) writes: >In article <111@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au (Warwick Allison) writes: >> Sounds like a TSR is necessary - so instruction space can be shared. Or just better/more consistent use of the shell_p pointer, eh? >i hope you mean shared text segments. if not, please fedex me a barf bag :-) Hm. How do you handle static variables in a shared library, anyway? -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
cae@sdfvm1.vnet.ibm.com ("Cornelius Caesar") (03/14/91)
boyd@nu.cs.fsu.edu (Mickey Boyd) writes: >Um, does anyone know how to figure out what postage to put on the SASE? Yes. >Do the stamps have to be German? I think the german Postal Offices accept only german stamps... > Could I just include $5 or something?!? I think $5 will be enough. Well, the postage for a letter is DM 1.- within Germany (if you keep the weight below 20g which is improbable with a 3.5" disk, DM 1.70 for a letter of up to 50g). Depending on the weight the international airmail fares to the USA are DM 1.65 for 5 g DM 1.90 for 10 g DM 2.15 for 15 g DM 2.40 for 20 g (1.40 + n*0.25 per 5 g up to 20 g) DM 3.35 for 25 g (2.10 + n*0.25 per 5 g up to 50 g) DM 3.60 for 30 g DM 3.85 for 35 g DM 4.10 for 40 g DM 4.35 for 45 g DM 4.60 for 50 g DM 5.55 for 55 g .... (the table is longer than that, ... ... I'll try to save bandwidth now) DM 127.- for 2000 g (this is MAXLETTERWEIGHT). Is it that what you wanted to know? By the way, 1 US$ is currently about DM 1.60 (rising). Cornelius cae@sdfvm1.vnet.ibm.com living in Ostelsheim, Germany
lunnon@qut.edu.au (03/15/91)
In article <1991Mar13.123427.11100@doe.utoronto.ca>, david@doe.utoronto.ca (David Megginson) writes: > > In <111@uqcspe.cs.uq.oz.au>, warwick@cs.uq.oz.au writes: >> >> Sounds like a TSR is necessary - so instruction space can be shared. >> Has anyobdy done any work on this idea? >> > > Eric Smith plans to add shared text segments to a later version of MiNT. > I am not sure exactly what this involves, but I imagine that he will come > up with some way of identifying a program which is already running > (same path and checksum?), and swap the .bss and .data in and out with > task changes. This would slow down MiNT a bit, but with programs like > bash(1) which is mostly .text, it would save a lot of memory. Comments? > Suggestions? If someone wants to write this themselves, it will show > up faster (Eric shouldn't have to do everything himself). > This would be nice but why doesn't someone take a standard ansi C library and make a shareable version taht can be loaded at boot time and there after used ( Via a trap for example ) then with the appropriate binding the text size of executable could be reduced by the size of the linked library. How about a coff loader for TOS and dynamic linking :-) BOB R.Lunnon@qut.edu.au > > David > > -- > //////////////////////////////////////////////////////////////////////// > / David Megginson david@doe.utoronto.ca / > / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / > ////////////////////////////////////////////////////////////////////////
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (03/16/91)
>This would be nice but why doesn't someone take a standard ansi C library >and make a shareable version taht can be loaded at boot time and there >after used ( Via a trap for example ) then with the appropriate binding >the text size of executable could be reduced by the size of the linked >library. How about a coff loader for TOS and dynamic linking :-) This could actually be done fairly easily; the main issue is what to do with program references to library data. You would have to either change all the compilers to make such references indirectly, or make the linker smart enough to copy the data (like errno) into your program, and have the runtime system smart enough so that the shared C library can reference data in your program. The latter is nontrivial. Also note that the libraries needn't be loaded at boot time; the startup code for the program could load libraries as appropriate, thus allowing arbitrary libraries to be shared on demand. As for static data in shared libraries, that is usually implemented in Unix implementations by the same "copy-on-write" mechanism used by fork() for program data segments. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
david@doe.utoronto.ca (David Megginson) (03/18/91)
Another problem with shared libraries is integer size. It would be possible to have the program end of the interface translate most function arguments consistently to 16-bit or 32-bit integers, but there are serious implications for functions like printf(). David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
lunnon@qut.edu.au (03/18/91)
In article <7340098@hpfcso.FC.HP.COM>, mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes: >>This would be nice but why doesn't someone take a standard ansi C library >>and make a shareable version taht can be loaded at boot time and there >>after used ( Via a trap for example ) then with the appropriate binding >>the text size of executable could be reduced by the size of the linked >>library. How about a coff loader for TOS and dynamic linking :-) > > This could actually be done fairly easily; the main issue is what to do with > program references to library data. You would have to either change all the > compilers to make such references indirectly, or make the linker smart enough > to copy the data (like errno) into your program, and have the runtime system > smart enough so that the shared C library can reference data in your program. > The latter is nontrivial. This is true but with limitations this could be simplified. Really when we deal with libraries they are pretty much black boxes, what we get depends on the implementation. Errno is really the only real problem point in the whole C library and ANSI defines it as an Lvalue Macro so any implementation which lets you write errno=87 will be ok. So if the library contains no reference to _errno then the global reference to the volatile name in the programs space will be used by the library. The real problem then is having the library know which errno to use at any time. This would have to be to be context sensitive. for example when a new process is started a pointer to a process link table be generated with all this type of data. This variable is kept in the process table in the OS and installed as the current application binding at each context switch or at each p_exec eg typedef struct process_static_table { int * errno; struct fileblock fb; int etc char **environment ... ... } ptable; ptable c_library; context_pt=&c_library; For user generated libraries, such static references are banned the errno Macro then in the library may be *(context_pt->errno) alternatively we can have *(get_errno_ptr()) where get_errno_ptr() is a function in the current programs space not the library. ie int *get_errno_ptr() ANSI cleared up a lot of this junk > > Also note that the libraries needn't be loaded at boot time; the startup code > for the program could load libraries as appropriate, thus allowing arbitrary > libraries to be shared on demand. True, but it _IS_ easier to load them at boot time :-) > > As for static data in shared libraries, that is usually implemented in Unix > implementations by the same "copy-on-write" mechanism used by fork() for > program data segments. I am told this is difficult with no MMU PS. Since I am talking off the top of my head, and because I am an engineer not a computer scientist, what I have said probably does not make the slightest sense and probably will not work. It is here merely to provoke thought. (No waranties whether implied or otherwise :-) (QUT does not pay me to write ramblings like this so don't blame them either ) BOB R.Lunnon@qut.edu.au PPS- Don't expect me to write this, I haven't even got around to re-developing a 2 ic interlace mod for posting yet, if you expect this, well ... Ha Ha Ha ... Ha Ha Ha Ha Ha Ha Ha Ha (recursion starts here) > > -------------- > Marc Sabatella (marc@hpmonk.fc.hp.com) > Disclaimers: > 2 + 2 = 3, for suitably small values of 2 > Bill and Dave may not always agree with me