gulam -- the best shell
Scott McMahan -- Genesis mailing list owner
MS DOS emulation for the ST.
Otherwise, GULAM has a lot going for it.
The utilities, like ls, cd, etc. are *built in* which means there's
no disk access time, loading the files into memory, and execution time
involved when you run the programs.
This is the biggest feature for me.
It has all the loops, etc. of other shells, which allows you to
write programs. I haven't figured out anyhting to write programs for yet...
It's almost exactly like UNIX.
It also has ue *built in*, which allows a very primitive job control
of either running or suspending ue...ue is very fast, since it's already
in memory.
Gulam also has a terminal emulator built in, but it's really crummy.
Shells like bas & tcsh are too big -- my ST really didn't like
bash & tcsh (it ran the korn shell, but what's a korn shell? :))
when I tired them. My st didn't like MINIX much, either :)
If someone came out with a smaller, more flexible tcsh for the st
with commands built in, I'd be the first to try it, but until then
I'll stick with gulam.
Scott
Alexander Lehmann
> First of all, I refuse to take anyone seriously who *wants* a
> MS DOS emulation for the ST.
>
> Otherwise, GULAM has a lot going for it.
>
> The utilities, like ls, cd, etc. are *built in* which means there's
> no disk access time, loading the files into memory, and execution time
> involved when you run the programs.
>
> This is the biggest feature for me.
>
> It has all the loops, etc. of other shells, which allows you to
> write programs. I haven't figured out anyhting to write programs for yet...
> It's almost exactly like UNIX.
>
> It also has ue *built in*, which allows a very primitive job control
> of either running or suspending ue...ue is very fast, since it's already
> in memory.
>
> Gulam also has a terminal emulator built in, but it's really crummy.
I agree that Gulam is a very fine shell, but it has some unpleasent features.
(Like a problem with command history.)
Can anybody tell me what the latest version of Gulam is, anyway.
Mine is dated somewhere is '88.
bye ... Alexander Lehmann
--
Alexander Lehmann | "Wopp" - lots of white, deadly robots
alex...@iti.informatik.th-darmstadt.de| from Krikkit ( THHGTTG Pt.3 )
Edd Deegan
>First of all, I refuse to take anyone seriously who *wants* a
>MS DOS emulation for the ST.
>
>Otherwise, GULAM has a lot going for it.
>
>The utilities, like ls, cd, etc. are *built in* which means there's
>no disk access time, loading the files into memory, and execution time
>involved when you run the programs.
>
>This is the biggest feature for me.
>
>with commands built in, I'd be the first to try it, but until then
>I'll stick with gulam.
>
>Scott
>
>
Standy....
I am currently nearing a beta-test version of a new shell called
SYNTH, which has over 60 of the commonest UNIX commands *built-in* with
the option to override any of them if you so wish....
Its looking good so far. When done I will release it as shareware, first
as a test-version, and then later as a 'proper' shareware program with
enhanced versions available to registered users. I will probably charge
about 4 English Pounds to register.
It should be similar to GULAM, but a hell of a lot friendlier, and a lot
more powerful in some areas - online help for a start!
Edd Deegan
va...@uk.ac.pcl.sun
Simon Kinahan
I don't really see why anybody wants to turn their ST into a green
screen terminal running a defective UNIX shell but I supose its up to
you.
Simon Kinahan akak sim...@castle.ed.ac.uk
Adam Turnbull
>
> I don't really see why anybody wants to turn their ST into a green
> screen terminal running a defective UNIX shell but I supose its up to
> you.
>
good for those who have just started out in the computing world, it's
certainly not good enough for more advanced work. This is perhaps
Atari's fault in part, since there are very few utilities that the
standard desktop boasts, especially when you consider other
replacements, such as Neodesk and Gemini. I'll admit desktops can be
useful, but you don't really have the contol that a good shell (such as
Gulam) can offer. Personally, I use Gemini when I can because it does
both things for me - a good desktop and a fairly decent shell. It's just
a pity it takes so long to load from floppy...
Adam
--
vvvvvvvvvvvvvvvvvvvvvvvvvvv @ @ vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> Adam Turnbull oo Democracy : It's your vote that counts <
> cs...@uk.ac.kl.seq1 ='= Feudalism : It's your count that votes <
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mike Healy
I like to turn my ST into a green screen terminal running a defective
UNIX shell so I can invoke the magic incantation "make" :-)
Mike Healy
William Rosenkranz
>screen terminal running a defective UNIX shell but I supose its up to
>you.
look: programmers generally prefer some sort of shell to work under since
it is generally faster to type that point an click. try it sometime on
something more substantiall than a "hello, world" code. gulam was one
of the first decent CLIs that just happens to emulate the unix csh. it is
still pretty good, especially for people with small memory/disk systems.
the alternatives (bash, tcsh, etc) tend to be huge, meaning you have to
be pretty serious about programming and hence have a substantial system.
can we stop this "you are stupid for using anything but {desktop,shell}..."
line? there are valid reasons for using both. just because you are
repulsed by the one you don't use doesn't mean someone else is not
equally repulsed by the other. for the record, i am on the "gulam" side
of the fence (and find anyone using the desktop to be... :-).
let's move on...
-bill
rose...@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rose...@convex.com
Kevin Donovan
sim...@arizona.edu (Simon Kinahan) writes:
> I don't really see why anybody wants to turn their ST into a green
>screen terminal running a defective UNIX shell but I supose its up to
>you.
Arggh, burn the heretic!!! 8-)
Seriously though, once your inside a program a GUI user interface can be
very helpful. OTOH, the desktop is far too limiting for programming (which
is obviously not to say that you can't, but working from a shell gives
you conveinent access to a host of tools that will make your life a lot
easier). Neodesk, Gemini, etc, whilst improvements, are really aimed at the
user rather than the programmer. Of course, all of this is merely a personal
opinion.
Kev
Michel Forget
>
> look: programmers generally prefer some sort of shell to work under since
> it is generally faster to type that point an click. try it sometime on
> something more substantiall than a "hello, world" code. gulam was one
> of the first decent CLIs that just happens to emulate the unix csh. it is
> still pretty good, especially for people with small memory/disk systems.
> the alternatives (bash, tcsh, etc) tend to be huge, meaning you have to
> be pretty serious about programming and hence have a substantial system.
>
> can we stop this "you are stupid for using anything but {desktop,shell}..."
> line? there are valid reasons for using both. just because you are
> repulsed by the one you don't use doesn't mean someone else is not
> equally repulsed by the other. for the record, i am on the "gulam" side
> of the fence (and find anyone using the desktop to be... :-).
>
> let's move on...
I'd like to ask a serious question; *WHY* is Gulam the CLI that everyone
likes so much. I can see the use of a CLI when working with programming
environments, but there are better shells than Gulam. How about Okami,
or the shell that comes with Gemini, or Bash? Bash is really large,
though, so that might be a disadvantage unless you have a real need of
something Bash offers. Okami is compact, and reliable. My experience
with Gulam was horrible, to say the least. The built-in Emacs crashed
(two bombs) two out of every three times I tried to use it. Aside from
that, the shell itself seemed to work moderately well. Nowhere near as
smoothly as Okami, though. The main problem with Okami is that it
doesn't offer the alias option, but uses functions instead. Mupfel does
offer aliasing, though, and just about all the other features you really
need. A CLI is great for programming, but not really useful for
every-day use.
<< ------------------------------------------ >>
<< mfo...@ersys.edmonton.ab.ca >>
<< ersys!mfo...@nro.cs.athabascau.ca >>
<< Michel Forget >>
<< "I'm the broken spoke in the Wheel Of >>
<< Time! Do you have a problem with that?" >>
<< ------------------------------------------ >>
David M. Baggett
>rose...@convex.com (William Rosenkranz) wisely writes:
>> can we stop this "you are stupid for using anything but {desktop,shell}..."
>> line? there are valid reasons for using both.
>
>likes so much. I can see the use of a CLI when working with programming
>environments, but there are better shells than Gulam. How about Okami,
>or the shell that comes with Gemini, or Bash?
File name completion. Built-in tools like grep. File name completion.
Aliases. Did I mention file name completion?
I've got a simple gulam alias so I can type "k" to make. You can't get
any simpler than "vi, fix bug, k, run program, vi, fix bug, k, ..."
without using an interpreted language. I'm not interested in touching
my mouse when I program since it's slower than typing "k." 1/2 :)
> A CLI is great for programming, but not really useful for
>every-day use.
Programming IS my every-day use. Gulam has many problems but I have
yet to see a more comfortable alternative. (Though the new shell that
was recently mentioned here sounds very good. I've been meaning to
try it out.)
Dave Baggett
d...@wam.umd.edu
William Rosenkranz
>likes so much. I can see the use of a CLI when working with programming
>environments, but there are better shells than Gulam. How about Okami,
>or the shell that comes with Gemini, or Bash? Bash is really large,
>though, so that might be a disadvantage unless you have a real need of
>something Bash offers. Okami is compact, and reliable. My experience
>with Gulam was horrible, to say the least. The built-in Emacs crashed
>(two bombs) two out of every three times I tried to use it. Aside from
>that, the shell itself seemed to work moderately well. Nowhere near as
>smoothly as Okami, though. The main problem with Okami is that it
>doesn't offer the alias option, but uses functions instead. Mupfel does
>offer aliasing, though, and just about all the other features you really
>need. A CLI is great for programming, but not really useful for
>every-day use.
gulam was among the first and free, probably. it has numerous problems,
but on the whole is very solid. i never use the builtin emacs or the term
stuff. i prefer MicroEMACS (3.9i or so, not the 3.10 stuff) and uniterm
for those things.
it also emulates unix (itself a religion :-) making it better than the
early MSDOS-ish CLIs. by early i am talking circa 1985-6. i keep wanting
to try okami, but have not had the time. is okami a unix workalike?
does it have common things like ls, rm, pwd, etc builtin? if not, i
don't think i'd be interested anyway. if so, i am. without alias,
okami is of no value to me.
i suspect i will eventually settle on tcsh/MiNT/MGR, once i have the
time to insure that it will operate as solidly as TOS/gulam. i also need
a small bourne shell (not bash) for make and other scripting. that way
i can have windows and shells, the best of all worlds, i suppose. since
i have used gulam since those heady days, and it has served me extremely
well (gulam, i believe, is a hindu word meaning "servant"), i have not
seen a major need to switch, in spite of its problems. i don't recall
every having lost data to a problem related to gulam itself. that is the
ultimate robustness test, i think. the old CWRU crew (bammi, et al)
deserve a lot of credit for their early and continuing work on making
the ST a truly nice little development system, if UNIX is your "thing".
that also can be a factor in gulam's continued use (stick with the things
that made life easy early on). i know this is the case for me, at least
in part. i respect those people and their early insight.
the biggest problem with gulam for me is no pipes. the TENEX stuff is of
marginal value anyway (IMHO). the use of the "|" would have been better
served for pipes vs its current use (which i confess i don't even remember
what it is now - never used it). the other problem is no source. i have
been told the source is a nightmare ("you really don't want to look at
it"). this is no longer a big problem with readily available source for
bash, ash, zsh, tcsh, etc. and a decent compiler/RTL (gcc).
a great CLI is extremely useful for "every-day use". it all depends on
your orientation. mine is supercomputing which means UNIX which means CLI.
BTW: i still use a VT100 clone in the office, even though i had a nice
X terminal (which i gave to one of my people). colleagues think i'm crazy
until they show up at a customer site who only has a VT100 for you to
work on :-). their productivity goes to hell and mine stays the same
(which is about the same if i had windows). i find "~^Z" and "fg" more
than adequate windowing system for UNIX :-). and my fingers never move
more than an inch. fortunately, i am a pretty good typist so this is not
a problem. those without such a skill usually find point/click more
productive. i have no problem with that. to each his/her own. it is good
that there is a choice. i have never seen a Mac with a shell. this would
be awful for me personally, though i could get used to anything (until
it was not available). the lowest common denominator of all the systems
i have worked on for the past 7 or 8 years has been VT100 and unix shells
and i expect that to be the case for a long time. i see no reason to
change (yet)...
-bill
rose...@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Michel Forget
> gulam was among the first and free, probably. it has numerous problems,
I'll grant that much; it was among the first and it was free. Still, I
think it could have been better. The version I had didn't look pleasing
at all, and with the bugs, I just decided to move onto something I liked.
> to try okami, but have not had the time. is okami a unix workalike?
> does it have common things like ls, rm, pwd, etc builtin? if not, i
> don't think i'd be interested anyway. if so, i am. without alias,
> okami is of no value to me.
Okami has far more built-in commands than Gulam, but the implementation
of aliasing is a little strange. Instead of using "alias xxx xxx" you
develop functions (like C) that do what you want. This is supposed to be
a better method, offering more flexability, but I'm not too sure. I
prefer being able to use alias commands. If Okami could support
aliasing, it would be the best shell around (in my opinion).
> a great CLI is extremely useful for "every-day use". it all depends on
> your orientation. mine is supercomputing which means UNIX which means CLI.
I have to admit that what you are saying here is true. I don't work in a
Computing field, so I don't work with CLI based systems often. My past
experience has all been with GUI interfaces, which is why I prefer them
for everyday use. I also like the simple fact that everything is BIGGER
with a GUI. I have bad eyesight, so I can lean back and still identify
the on-screen images. I also don't have to worry about typing a great
deal, although that isn't a consideration with a shell that can support
aliasing. If I had to use CLI systems all day at work, then I suppose I
would prefer to use a CLI at home. Like you said, what you are used to
is what you will use. I'm getting off the topic though; the original
question was why *Gulam* and not why CLI. I think the best combination
of programs for a system would be this:
1. MiNt
2. Gemini (with Mupfel)
3. MiNT utilities that come with the package.
With Gemini, you have a GUI, and Mupfel gives you a great CLI. The MiNT
utilities (BG, LIMIT, KILL, etc.) could allow you to control processes
easily enough. I've never seen MGR, and the oly thing I know about it is
that it is supposed to use a great deal of memory. Even with the setup I
have now (no MiNT installed) I only have about 787K free on a 2 Megabyte
machine. I'm thinking about installing MiNT again, but I'm not sure how
well it will work with my Terminal program. I've noticed it doesn't work
with Tempus, or the Personal Pascal editor, or really any window-oriented
program that tries to cheat to speed things up. Even Interlink refuses
to work properly (it won't take keypresses when in on-line mode. The
keys you press show up in the buffer as if you had typed them there
instead of online.)
> -bill
> rose...@convex.com
> --
> Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
> Convex Computer Corp. |ARPA: rose...@convex.com
Hans-Peter Nollert
[...]
>something Bash offers. Okami is compact, and reliable. My experience
>with Gulam was horrible, to say the least. The built-in Emacs crashed
>(two bombs) two out of every three times I tried to use it. Aside from
>that, the shell itself seemed to work moderately well. Nowhere near as
>smoothly as Okami, though. The main problem with Okami is that it
>doesn't offer the alias option, but uses functions instead. Mupfel does
[...]
A word of warning from somebody who got just the opposite impression
about Okami:
Regarding its features, Okami looks great. And yes, the current
version (1.4+) has an alias, even thoug I agree with the author that
the shell functions are more flexible than an alias.
However, after trying to work with Okami for about a week, I gave up,
totally frustrated. I found Okami to be extremely unstable and
sensitive against any error on my part. I had to reboot about every
ten minutes or so! Forgetting the second ` in a command substitution,
for example, caused the Atari to hang, making a reboot necessary. In
some cases, it even needed a cold start, destroying my reset-proof ram
disk. In other cases, it seemed that Okami didn't close files used in
pipes properly, causing the open file limit to be exceeded.
If you are used to Unix, don't expect " or ' or $i to work in the same
way in Okami, even though it sounds like this from the documentation.
In fact, I haven't managed to work out just exactly how these work.
Also, I couldn't get gawk to work properly in a pipe under Okami,
which is a big problem because I use gawk a lot. (And yes, I have read
the documentation that came with Okami more than once, but still found
myself pretty much lost.)
You could always blame the problems on me for making mistakes during
interactive input or in shell scripts, but a shell which needs a
reboot almost every time I make a mistake is unacceptable for me.
Hoewever, if you are the type who finds such problems a challenge
rather than a nuisance, Okami might be for you. It DOES have a lot of
features...
Hans-Peter
--
Lehr- und Forschungsbereich Theoretische Astrophysik (TAT),
Universitaet Tuebingen, Auf der Morgenstelle 10, D-7400 Tuebingen, Germany
Tel.: 49-7071-295921 Telefax: 49-7071-295400 Telex: 726 2867 UTNA D
nol...@tat.physik.uni-tuebingen.de PSI%45050260314::NOLLERT
Ralph P. Sobek
>>>>> (David M. Baggett) writes:
dmb> File name completion. Built-in tools like grep. File name completion.
dmb> Aliases. Did I mention file name completion?
Yes you did, and I LOVE IT!!!
dmb> I've got a simple gulam alias so I can type "k" to make. You can't get
dmb> any simpler than "vi, fix bug, k, run program, vi, fix bug, k, ..."
dmb> without using an interpreted language. I'm not interested in touching
dmb> my mouse when I program since it's slower than typing "k." 1/2 :)
This does not show gulam's other utilities. I use the much more
simpler sequence: "fg, fix bug, !m, run program, ...." Here "fg"
brings me back to gulam's editor "ue" in the current buffer that I am
debugging at the current postion that I am interested. "!m" use
gulam's history to rexecute the last "make" with all its arguments.
Most often, I use "!" again to rerun the program test.
dmb> (Though the new shell that was recently mentioned here sounds
dmb> very good. I've been meaning to try it out.)
Yes, I also mean to try it out some day, rsn.
--
Ralph P. Sobek Disclaimer: The above ruminations are my own.
ra...@laas.fr Addresses are ordered by importance.
ra...@laas.uucp, or ...!uunet!laas!ralph
If all else fails, try: so...@eclair.Berkeley.EDU
Phone: (+33-)61-33-62-66 FAX-1: (+33-)61-33-64-55 FAX-2: (+33-)61-55-35-77
===============================================================================
Got a Mega 4 ST. Wish it was a Mega STe? :-| Do I *really* want a TT/Next? ;~#
Paul Sammy 3rd Year iE
Does anyone fancy giving a quick summary on the various shells available?
I've only used Gulam. It seems pretty good to me, although I hate the
way it is so mouse senstitive- I usually toss the mouse off the desktop altogether.
Incidently, one of the best things I like about Gulam is probably an installation
mistake. The gulam I ftped off the net was configured for US keyboards.
This means that (on a UK keyboard) the "#" below the ENTER/RETURN key
is translated as a "~". This is v. useful if you use a PC keyboard all day.
I just avoid looking at the keyboard and type.
Paul
--
"Bark?" | Internet: ssa...@cs.strath.ac.uk
-Moving Pictures | JANET : ssa...@uk.ac.strath.cs
Mickey Boyd
>
>I'd like to ask a serious question; *WHY* is Gulam the CLI that everyone
>likes so much. I can see the use of a CLI when working with programming
>environments, but there are better shells than Gulam. How about Okami,
>or the shell that comes with Gemini, or Bash? Bash is really large,
>though, so that might be a disadvantage unless you have a real need of
>something Bash offers. Okami is compact, and reliable. My experience
>with Gulam was horrible, to say the least. The built-in Emacs crashed
>(two bombs) two out of every three times I tried to use it. Aside from
>that, the shell itself seemed to work moderately well. Nowhere near as
>smoothly as Okami, though. The main problem with Okami is that it
>doesn't offer the alias option, but uses functions instead. Mupfel does
>offer aliasing, though, and just about all the other features you really
>need. A CLI is great for programming, but not really useful for
>every-day use.
>
Gulam is the only csh (or "almost csh") clone for the ST with english docs
that I have found. Okami is great, but it is a Bourne shell clone, not
csh. I have never had a problem with ue, so it might be some auto folder
program or desk accessory that is giving you problems.
As for CLI's being good only for programming, I would disagree. I find that
complex file operations are much easier in Gulam. For general "boot up and
run stuff" type use, I like Neodesk. By placing Gulam on the Neodesk desktop
(I even drew a little sea-shell icon for it), I have the best of both worlds.
--
---------------------------------+-------------------------------------
Mickey R. Boyd | "Come to your senses professor
FSU Computer Science | Fernberg. You did not transcend
Technical Support Group | the time-space continuum. You
email: bo...@nu.cs.fsu.edu | got drunk in a topless bar."
---------------------------------+-------------------------------------
Neil Forsyth
>likes so much.
(In not more than 100 words :-)
I use Gulam all the time and could not live without it because:-
It has loads of built in commands that I use all the time
like cp,rm,mv,ls
It has a good (not perfect) shell script language
It has built in microEmacs. My favourite editor.
Filename completion. I wish it had command completion as well.
History.
EMacs command line editing
It's small. Some of my friends manage to use Sozobon C on a 520ST
with it.
A lot of shells provide some ofthe above features but only Gulam seems to be
providing so many. It is a matter of constant sadness to me that Prabhaker
Mateti stopped working on it.
If I were to stop using Gulam in favour of some other shell it would be nice
to have the following additional features:-
Selectable builtin commands so that we can save RAM by leaving out
the ones we don't want. A special executable format would allow
the modules to be run as normal programs or shell resident parts.
Built in disposable RAM disk. A command would make the shell allocate
some RAM for it and install a driver. Another command would destroy
the RAM disk. This would allow temporary files during compilation
to go to a RAM disk for speed but also allow the final application
to get maximum amount of RAM without having to reboot.
(I have 4Mb so this is not a problem for me but others would benefit)
A history save command that could be used before running dangerous
programs that are under development.
+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
! !
! Neil Forsyth JANET: ne...@uk.ac.hw.cs !
! Dept. of Computer Science ARPA: ne...@cs.hw.ac.uk !
! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil !
! Edinburgh, Scotland, UK "That was never 5 minutes!" !
+----------------------------------------------------------------------------+
William Magro
|> In article <cqZwgB...@ersys.edmonton.ab.ca> mfo...@ersys.edmonton.ab.ca
|> (Michel Forget) writes:
|> >I'd like to ask a serious question; *WHY* is Gulam the CLI that everyone
|> >likes so much.
|>
|> (In not more than 100 words :-)
|>
|> I use Gulam all the time and could not live without it because:-
|>
|> It has loads of built in commands that I use all the time
|> like cp,rm,mv,ls
|>
|> It has a good (not perfect) shell script language
|>
|> It has built in microEmacs. My favourite editor.
|>
|> +----------------------------------------------------------------------------+
|> ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
|> ! !
|> ! Neil Forsyth JANET: ne...@uk.ac.hw.cs !
|> ! Dept. of Computer Science ARPA: ne...@cs.hw.ac.uk !
|> ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil !
|> ! Edinburgh, Scotland, UK "That was never 5 minutes!" !
|> +----------------------------------------------------------------------------+
On my machine:
roma_40% wc
(above stuff inserted)
40 264 1478
roma_41%
So much for inequalities *:^)
--Bill
Ralph P. Sobek
>>>>> ssa...@cs.strath.ac.uk (Paul Sammy 3rd Year iE) writes:
Paul> Does anyone fancy giving a quick summary on the various shells available?
Paul> I've only used Gulam. It seems pretty good to me, although I hate the
Paul> way it is so mouse senstitive- I usually toss the mouse off the
Paul> desktop altogether.
This one is easy! Place 'set msoff' in your gulam.g file
Paul> The gulam I ftped off the net was configured for US keyboards.
Paul> This means that (on a UK keyboard) the "#" below the ENTER/RETURN key
Paul> is translated as a "~". This is v. useful if you use a PC
Paul> keyboard all day.
I'm not sure whether you appreciate this or not. Anyhow, there exists
a companion program, KEYFIX.TOS or KEYEDIT.PRG I believe, that
reconfigures GULAM to your local keyboard. As such I have *no*
problems with my weird French keyboard.
Paul Sammy 3rd Year iE
>>>>>> In article <SSAMMY.92...@lister-02.cs.strath.ac.uk>,
>>>>>> ssa...@cs.strath.ac.uk (Paul Sammy 3rd Year iE) writes:
>Paul> Does anyone fancy giving a quick summary on the various shells available?
>Paul> I've only used Gulam. It seems pretty good to me, although I hate the
>Paul> way it is so mouse senstitive- I usually toss the mouse off the
>Paul> desktop altogether.
> This one is easy! Place 'set msoff' in your gulam.g file
Hmm, I'm sure I tried that before.
Anyway, I'll do it again.
Thanks for the KEYFIX.TOS info.
I'll keep it in mind!
Paul
--
"Bark?" | Internet: ssa...@cs.strath.ac.uk
-Moving Pictures | JANET : ssa...@uk.ac.strath.cs
Copy this line into your .signature to protect it against viruses! [version -9]
Russell Kallen
> systems, and other extensions to the system. It is quite
> compatible, but has trouble with some GEM programs that cheat on
> window scrolling. I'm not sure why. MiNT is not very hard on
Can you explain that -- what does it mean to "cheat on window
scrolling"?
> memory (150K I think) and it works fine with just about any
> shell. Better from a shell, in fact. There are some utilities
Which shell(s) does it run most efficiently with? I could guess
that GULAM would be one, but I've heard that GULAM doesn't
support certain MINT features, e.g., job control.
By the way, that's a great surname you've got:
- "What is your name?"
- "I forget."
- "Hmm, yes you are aren't you?"
Kevin Donovan
ne...@uunet.uu.net (Neil Forsyth) writes:
>A lot of shells provide some ofthe above features but only Gulam seems to be
>providing so many. It is a matter of constant sadness to me that Prabhaker
>Mateti stopped working on it.
Craft (distributed in the UK by Hisoft) does all of the above, except for
the builtin microemacs. It does come with a very nice editor.
> Built in disposable RAM disk. A command would make the shell allocate
Craft has this.
> A history save command that could be used before running dangerous
> programs that are under development.
And this. Simply echo the history to a file, then source the file when you wan-
t
to reload it.
My main criticism of Craft is that it doesn't live very well with Mint, nor
does the editor. For this reason I now use tcsh and Gnu Emacs.
Kev
Michel Forget
> This is actually in reply to another, related article (re: MINT) --
>
> > systems, and other extensions to the system. It is quite
> > compatible, but has trouble with some GEM programs that cheat on
> > window scrolling. I'm not sure why. MiNT is not very hard on
>
> Can you explain that -- what does it mean to "cheat on window
> scrolling"?
I was talking about programs like Tempus II and the Personal Pascal
editor. These programs are VERY fast when they scroll through text in
their windows. Much faster than other programs. At any rate, that is
the only obvious difference between those and programs that don't do
super-fast scrolling (but stay alive under MiNT.)
>
> > memory (150K I think) and it works fine with just about any
> > shell. Better from a shell, in fact. There are some utilities
>
> Which shell(s) does it run most efficiently with? I could guess
> that GULAM would be one, but I've heard that GULAM doesn't
> support certain MINT features, e.g., job control.
Which shells? I'm not really all that sure about this one. I've heard
it works fine under Gulam. All you have to do is use the utilities that
come with MiNT that you can put in your BIN directory to support job
control. The best shell to use is the one that comes with it. It has
the utilities all built-in, so there is no wait.
>
> By the way, that's a great surname you've got:
>
> - "What is your name?"
> - "I forget."
> - "Hmm, yes you are aren't you?"
Oh, wonderful. Yet another bad joke...:) Actually, the most common
response is "are you lying?" when someone asks.
Andrew H Krieg
use the built in ue. I've just aliased vi to run stevie (although stevie
does have its limitations with large files).
The only part of gulam that pisses me off is if you backspace too far, you
get the previous command from your history list. Does anyone know of a way
to prohibit gulam from doing this?
--
= Andrew Krieg | =
= kr...@titan.med.ge.com| Treguna Mekoides Trecorum Satis Dee =
= or | =
= kr...@point.cs.uwm.edu| - Astoroth =
Ralph P. Sobek
>>>>> (Paul Sammy 3rd Year iE) adds:
Paul> Thanks for the KEYFIX.TOS info.
Paul> I'll keep it in mind!
You're welcome!
The problems that people seem to have with GULAM is that they might be
running a crippled version. Actually, only an early version seems to
have been delivered with full EMACS-like functionality.
I have received e-mail on this subject from Alexander Lehmann
<alex...@iti.informatik.th-darmstadt.de> and Neil Forsyth
<ne...@cs.heriot-watt.ac.uk>. Both these people seem to have the
*feature* (I would call it a bug!) that they use ESC for filename
completion.
I am posting this in case others have this same *feature*! This
feature inhibits a lot of GULAM's emacs-like functionality. Normally,
emacs (be it gnu, mg, etc.) ESC functions as a key modifier as does
C-X (control X). Adding the following to your gulam.g file
reestablishes gulams use of ESC as key modifier:
kb -m 15b 71 # allow ESC as meta-key
kb -r 54c 26 # C-X C-L = goto-line
The second line is *not* necessary; it just shows how one can redefine
or add key-bindings.
What does this get you, you might ask? Well first of all TAB becomes
file-name completion in the minibuffer or just under gulam. The new
commands that are possible are defined in the file gulam.hlp, if you
have it. In addition, if you have the following (with your path of
course) also in your gulam.g file:
set gulam_help_file c:\gulam\gulam.hlp
then you get online documentation when you're under `ue' (gulam's
internal emacs). Here are excerpts from the file to show the *new*
commands that become available when ESC is a key modifier (with common
definitons added by me as comments):
gulam.hlp -- help file for Gulam
#1 keycode (in hex) to keyname (rest of line) table
[...]
220 ESC SPC # just-one-space
221 ESC ! # execute-one-Gulam-cmd
225 ESC % # query-replace
22e ESC .
23c ESC < # beginning-of-buffer
23e ESC > # end-of-buffer
242 ESC B # backward-word
243 ESC C # capitalize-word
244 ESC D # kill-word
246 ESC F # forward-word
247 ESC G
24c ESC L # downcase-word
252 ESC R
253 ESC S
255 ESC U # upcase-word
256 ESC V # scroll-up
257 ESC W # copy-region-as-kill
27f ESC DEL # kill-backward-word
346 ESC C-F
348 ESC C-H
35b ESC ESC
[...]
#2 function-code (hex) to function name etc
000 no-op
001 show-possible-expansions
002 expand-name
003 terminate-mini-buffer
004 file-name
005 expand-name-gulam-style
006 switch-to-gulam-buffer
007 execute-buffer
008 read-file
009 show-key-board-macro
00a terminal-emulator
00b move-window-up
00c move-window-dn
00d quick-exit
00e temporary-exit
00f gulam-forward-line
010 gulam-do-newline
011 goto-next-tab
012 save-buffers-kill-emacs
013 keyboard-quit
014 help
015 start-kbd-macro
016 end-kbd-macro
017 call-last-kbd-macro
018 no-op
019 redraw-display
01a backward-char
01b forward-char
01c backward-delete-char
01d delete-char
01e beginning-of-line
01f goto-end-of-line
020 kill-line
021 next-line
022 open-line
023 previous-line
024 insert-newline
025 newline-and-indent
026 goto-line
027 execute-one-Gulam-cmd
028 no-op
029 no-op
02a no-op
02b search-backward
02c search-forward
02d no-op
02e no-op
02f query-replace
030 set-mark-command
031 self-insert
032 recenter
033 quoted-insert
034 transpose-chars
035 copy-region-as-kill
036 kill-region
037 keys-reset
038 no-op
039 no-op
03a no-op
03b yank
03c no-op
03d find-file
03e save-buffer
03f write-file
040 no-op
041 delete-blank-lines
042 exchange-point-and-mark
043 what-cursor-position
044 next-window
045 previous-window
046 shrink-window
047 enlarge-window
048 no-op
049 delete-other-windows
04a split-window-vertically
04b ctrlx-four-hack
04c no-op
04d insert-buffer
04e switch-to-buffer
04f no-op
050 list-buffers
051 kill-buffer
052 save-some-buffers
053 no-op
054 end-of-buffer
055 beginning-of-buffer
056 no-op
057 no-op
058 no-op
059 just-one-space
05a backward-word
05b capitalize-word
05c kill-backward-word
05d kill-word
05e forward-word
05f downcase-word
060 upcase-word
061 scroll-up
062 scroll-down
063 no-op
064 no-op
065 no-op
066 no-op
067 no-op
068 no-op
069 no-op
06a no-op
06b blink-matching-paren-hack
06c no-op
06d no-op
06e describe-key-briefly
06f produce-wall-chart-describe-bindings
070 NUL
# -eof-
Hope that someone finds all this useful!
Paul Sammy 3rd Year iE
> people seem to have the
> *feature* (I would call it a bug!) that they use ESC for filename
> completion.
hmm, I admit I thought it was because csh uses ESC for completion...
> I am posting this in case others have this same *feature*! This
> feature inhibits a lot of GULAM's emacs-like functionality. Normally,
> emacs (be it gnu, mg, etc.) ESC functions as a key modifier as does
> C-X (control X).
Great!!
I always thought that this was because the ue was a "baby"emacs.
> Adding the following to your gulam.g file
> reestablishes gulams use of ESC as key modifier:
> kb -m 15b 71 # allow ESC as meta-key
> kb -r 54c 26 # C-X C-L = goto-line
> The second line is *not* necessary; it just shows how one can redefine
> or add key-bindings.
erm, whats the switchs for?
-m == modify keymap yeah?
whats -r mean?
And how do I determine which control sequence equals what code?
[gratefully received help deleted for brevity]
> Hope that someone finds all this useful!
Most certainly.
What is the most upto date version of gulam? Or better yet, where can
I get the latest version by ftp?
regards Paul
> --
> Ralph P. Sobek Disclaimer: The above ruminations are my own.
> ra...@laas.fr Addresses are ordered by importance.
> ra...@laas.uucp, or ...!uunet!laas!ralph
> If all else fails, try: so...@eclair.Berkeley.EDU
--
"We should develop anti-satellite weapons| Internet: ssa...@cs.strath.ac.uk
because we could not have prevailed | JANET : ssa...@uk.ac.strath.cs
without them in 'Red Storm Rising'." |
-- Vice President Dan Quayle |
Dave Hines
re-establish gulams use of the ESC key as the 'meta' key modifier. Does
anyone know if it is possible for gulam to use the alt key as a meta key ?
I am accustomed to having a real meta key when using GNU EMACS on a sun,
and it would be nice to have this on my ST as well.
Dave Hines.
--
Dave Hines.
JANET: D.H...@uk.ac.daresbury
EARN/BITNET: D.Hines%daresbury.ac.uk@UKACRL
UUCP: D.Hines%daresbu...@ukc.uucp
Ean: D.Hines%daresbu...@ean-relay.ac.uk
Internet: D.Hines%daresbury.ac.uk or D.Hines%dare...@nsfnet-relay.ac.uk
Ken Newman
> In <RALPH.92M...@orion.laas.fr>, Ralph P. Sobek describes how to
> re-establish gulams use of the ESC key as the 'meta' key modifier.
Well, I don't know what all the fuss is about - my copy of Gulam uses
ESC as the filename completer and the meta key in Emacs, works fine.
I use ESC < and ESC > all the time to go to beginning and end of file.
--
k...@isgtec.com [ ...!uunet.ca!isgtec!ken ] Ken Newman
Ralph P. Sobek
even if it is out of date, slightly.
>>>>> In article <SSAMMY.92M...@simpson-04.cs.strath.ac.uk>,
>>>>> ssa...@cs.strath.ac.uk (Paul Sammy 3rd Year iE) writes:
I wrote:
> Adding the following to your gulam.g file
> reestablishes gulams use of ESC as key modifier:
> kb -m 15b 71 # allow ESC as meta-key
> kb -r 54c 26 # C-X C-L = goto-line
> The second line is *not* necessary; it just shows how one can redefine
> or add key-bindings.
Paul> erm, whats the switchs for?
Paul> -m == modify keymap yeah?
The switchs tell gulam which keyboard table should be modified: -r =
regular buffer, -m = mini-buffer, and -g = gulam ue buffer. Gulam
outside of ue is in the min-buffer.
Paul> And how do I determine which control sequence equals what code?
Well, the gulam help file is a start. I read it to do the above!
Don't remember anymore how.
--
Ralph P. Sobek Disclaimer: The above ruminations are my own.
ra...@laas.fr Addresses are ordered by importance.
ra...@laas.uucp, or ...!uunet!laas!ralph
If all else fails, try: so...@eclair.Berkeley.EDU
Mickey Boyd
>
>The problems that people seem to have with GULAM is that they might be
>running a crippled version. Actually, only an early version seems to
>have been delivered with full EMACS-like functionality.
>
>I have received e-mail on this subject from Alexander Lehmann
><alex...@iti.informatik.th-darmstadt.de> and Neil Forsyth
><ne...@cs.heriot-watt.ac.uk>. Both these people seem to have the
>*feature* (I would call it a bug!) that they use ESC for filename
>completion.
I would call it a feature, as it emulates the good 'ol csh. I have been
using csh (with the filec option set) for years, and I was very pleased to
find that Gulam supports this. I do see how this would be annoying to a
ue user (I am a vi guy myself, so I use STevie which interprets the [esc]
key just fine), but one could always use GNU emacs or MicroEmacs (and I
think there are a few more).