🚀 go-pugleaf

naddy@mips.ruessel.sub.org (Christian Weisgerber) writes:

>Ich suche eine _gute_ Shell (CLI) fuer den ST...

>Empfehlungen?
>Bitte mit Versionsangabe! Ich habe hier noch etliche Shells rumliegen,
>aber die sind groesstenteils mehrere Jahre alt. Bezugsquelle waere auch
>nicht schlecht.

Nun gut, ich bin auch gerade auf der Suche nach einer Shell, die meinen
Wuenschen 100%ig entspricht, deshalb hier meine Erfahrungen:

Mupfel aus der Gemini-Distribution, Version 1.21. Sehr empfehlenswert,
wenn man auf Kleinigkeiten verzichten kann.
Die tcsh in der Version 6.02. Gross aber fein.

>Anforderungen:
>- Alias, History, Kommandozeilen-Editor, Filenamenexpansion

Koennen beide. Unter Filenameexpansion kann ich mir jetzt nicht richtig
vorstellen, was Du meinst. Die tcsh bietet Filename-completion (TAB oder
ESC ESC). Wildcards koennen beide gut verarbeiten (z.B. cd c:\ab*\to_*)

>- sinnvolle Expansionsreihenfolge fuer Alias, History, Variablen und
>  brauchbare Quotierung

Scheint mir eher ein objektiver Aspekt zu sein. Besser selbst
ausprobieren. Das Quoten liegt in der Mupfel noch ein wenig im Argen,
doch die neueste Beta-Version verspricht Besserung.

>- Environment-Verwaltung
>- I/O-Umleitung, Pipes

Das ist wohl Standard. Es gibt ein pipe.ttp fuer tos, das aber in der
tcsh nicht funktioniert (can't make pipe). Abhilfe: MiNT

>- kein MiNT notwendig

Tja, die Mupfel laeuft unter MiNT, kann aber keine Hintergrundprogramme
verwalten. Beim Verlassen von der Mupfel gibt es bisweilen
System-Lockups :-(

>- stabil

Beide einwandfrei.

>zusaetzliche Wunschvorstellungen (nicht unbedingt notwendig):
>- einigermassen kompakt

Beide sind wohl eher gross, wenn man die Mupfel ohne Gemini aufruft, ist
es tragbar. Aber wer hat schon weniger als 2MB?

>- GEM-Programme daraus aufrufbar

Mupfel: Kein Problem. tcsh: Hab ich nie getestet.

>- Scriptsprache, sh oder csh-Subset/-aehnlich

fuer die Mupfel gibt es einige Zusatz-ttp Programme (if etc.). Inwiefern
das in die tcsh eingebaut ist, weiss ich jetzt nicht...

>- auf die Serielle umleitbar, termcap-faehig

Ich habe es noch nicht geschafft, die Mupfel auf die serielle zu
kriegen. Bei der tcsh duerfte es keine Probleme geben.

>FYI, ich benutze z.Zt. die CLI 1.0x von Oliver Scholz.  Die hat zwar
>einige nette Features und ist angenehm klein, aber der Parser ist total
>"broken".

Kenn ich nicht, aber ich werde demnaechst mal die Okami Shell in der
Version 1.5 testen. Gulam faellt aus, wegen hohem Alter, vieler Fehler
und Ballast (z.B. eigener Editor). Ausserdem unterstuetzt sie kein
shell_p (was das auch immer ist). Dadurch kann auf jeden Fall der nn an
die Shell Aufrufe schicken.

Bitte schreib mir Deine Erfahrungen! Was willst Du mit der Shell denn
anfangen? Ich benutze meine Shell ueberwigend fuer mein uucp-System und
kann es noch garnicht fassen, dass ich total mausfaul geworden bin! :-)

>Thanx
>-- 
>Christian "naddy" Weisgerber, Germany           naddy@mips.ruessel.sub.org

Knarf
-- 
+-----------------------------------------------------------------+
| Frank Bartels - knarf@nasim.sta.sub.org - Munich - West-Germany |
+-----------------------------------------------------------------+

Frank Bartels writes:

> Mupfel aus der Gemini-Distribution, Version 1.21. Sehr empfehlenswert,
> wenn man auf Kleinigkeiten verzichten kann.
> Die tcsh in der Version 6.02. Gross aber fein.

Die tcsh kenne ich von Unix her. *Wie* gross ist die denn auf dem ST?
Fragt sich, ob ein derartiges Unix-Werkzeug auf einem Schrumpfrechner,
wie dem ST, sinnvoll ist.

> Koennen beide. Unter Filenameexpansion kann ich mir jetzt nicht richtig
> vorstellen, was Du meinst.

Das war mein missglueckter Versuch Filename Completion einzudeutschen.
Kann Mupfel das auch? Ist fuer mich ein essentielles Feature.
Fragt sich auch ob, die jeweilige Shell das richtig kann: also auch
z.B. ..\..\blaf_ expandieren

> >- sinnvolle Expansionsreihenfolge fuer Alias, History, Variablen und
> >  brauchbare Quotierung
> Scheint mir eher ein objektiver Aspekt zu sein. Besser selbst
> ausprobieren. Das Quoten liegt in der Mupfel noch ein wenig im Argen,
> doch die neueste Beta-Version verspricht Besserung.

Ja, ich weiss warum ich frage. Mit dem Teil, das ich gerade benutze,
kann ich z.B. nicht mehrere Befehle durch ';' getrennt in einen Alias
packen, egal wie ich quote, ';' wird immer vor den Quotes ausgewertet.

> >- I/O-Umleitung, Pipes
> Das ist wohl Standard. Es gibt ein pipe.ttp fuer tos, das aber in der
> tcsh nicht funktioniert (can't make pipe). Abhilfe: MiNT

Standard? Naja. Vielleicht hat es sich mit den letzten TOS-Versionen
gebessert, aber die I/O-Umleitung lag beim ST schon immer im argen.
Abstuerze, schlichtes Nicht-Funktionieren, kein EOF von einem Device...

Mit Pipes meine ich, dass sowas wie "lha l archiv | more" klappt. Das
sollte so ablaufen, dass zuerst die Ausgabe in ein temporaeres File
geleitet, danach die Eingabe aus diesem genommen wird. Nicht so ganz
dasselbe wie unter Unix...

> Tja, die Mupfel laeuft unter MiNT, kann aber keine Hintergrundprogramme
> verwalten.

Klar, wenn ich multitasken will, dann brauche ich MiNT. Ob ich das aber
will, oder das auf einem ST ueberhaupt sinnvoll ist, das ist eine ganz
andere Frage. Mir geht es im Moment nur um streng sequentielle Prozess-
abarbeitung.

> Beide sind wohl eher gross, wenn man die Mupfel ohne Gemini aufruft, ist
> es tragbar. Aber wer hat schon weniger als 2MB?

Ich habe 4MB, aber ich moechte vermeiden, dass ich auf ein Szenario
komme, wie:
- 256kB-TOS im RAM (habe ich z.Zt.)
- MiNT
- Shell
- oops, kein Platz mehr fuer gcc.

> Version 1.5 testen. Gulam faellt aus, wegen hohem Alter, vieler Fehler
> und Ballast (z.B. eigener Editor). Ausserdem unterstuetzt sie kein
> shell_p (was das auch immer ist). Dadurch kann auf jeden Fall der nn an
> die Shell Aufrufe schicken.

Gulam hatte ich frueher einmal, ich habe auch nichts von neueren
Versionen gehoert. Gulam ist arg instabil, grauselig dokumentiert
(obwohl mir das heute vermutlich nicht mehr soviel ausmachen wuerde),
und der ue taugt eh nichts, ist also wirklich ueberfluessig.

shell_p ist ein wirklich nettes Feature. Das ist ein Pointer der auf die
Kommadozeilenauswertroutine der Shell zeigt. Die kann mit einer
Kommandozeile als Parameter von einem Child-Prozess aufgerufen werden,
und wird dann ausgefuehrt. Als system()-Aufruf bekannt.

Hatte ich vergessen zu erwaehnen, das sollte auch unterstuetzt werden.

> Bitte schreib mir Deine Erfahrungen! Was willst Du mit der Shell denn
> anfangen? Ich benutze meine Shell ueberwigend fuer mein uucp-System und
> kann es noch garnicht fassen, dass ich total mausfaul geworden bin! :-)

Was man so alles mit einer Shell macht. Durch knapp sieben Jahre
Konfrontation mit Ataris GEM und "benutzerfreundlichen" Programmen, ist
mir ein Kommandozeileninterface einfach lieber. Fuer Hermes brauche ich
sie natuerlich auch, ausserdem moechte ich Kleingkeiten einfach per
Shell-Script erledigen lassen koennen. Ich sage nur grep, sed, awk
(BTW, hat jemand ein brauchbares standalone-grep fuer den ST?), sowas
sagt mir nun mal mehr zu als klick-klick-Fenster-zerr-Menue-reiss-klick-
verzweifel-weils-doch-nicht-geht-klick...

-- 
Christian "naddy" Weisgerber, Germany           naddy@mips.ruessel.sub.org

In <H.eg.YDjCU1QPq4g@mips.ruessel.sub.org> naddy@mips.ruessel.sub.org (Christian Weisgerber) writes:

>Ich suche eine _gute_ Shell (CLI) fuer den ST...

>Empfehlungen?
>Bitte mit Versionsangabe! Ich habe hier noch etliche Shells rumliegen,
>aber die sind groesstenteils mehrere Jahre alt. Bezugsquelle waere auch
>nicht schlecht.

>Anforderungen:
>- Alias, History, Kommandozeilen-Editor, Filenamenexpansion
>- sinnvolle Expansionsreihenfolge fuer Alias, History, Variablen und
>  brauchbare Quotierung
>- Environment-Verwaltung
>- I/O-Umleitung, Pipes
>- kein MiNT notwendig

 warum?  ohne MiNT entgeht dir was, grade auf der shell.  ich sag nur
`richtige' pipes, backgroundprozesse, job control... (zB koennt ich
jetzt einfach ^Z tippen, nen uucico starten, und dann waehrend der
laeuft hier weiterschreiben...  usw. :-)

>- stabil

 naja es gibt ne gnulib- (also nicht-MiNT) bash, die andern guten
(== un*x) shells die ich kenn (ksh, tcsh) brauchen aber alle MiNT.
(oder koennen ohne wenigstens nicht pipen, etc.)

>zusaetzliche Wunschvorstellungen (nicht unbedingt notwendig):
>- einigermassen kompakt

 ja genau, zB entgeht dir dann auch dass MiNT ab 0.96beta shared
text kann, damit braucht ne 2. shell kein speicher mehr fuers
textsegment wenn sie mit MiNTlibs und gcc -mbaserel compiliert ist...

>- GEM-Programme daraus aufrufbar

 dafuer hab ich hier so ein rg.prg, das tuts einigermassen...

>- Scriptsprache, sh oder csh-Subset/-aehnlich

 versteht sich jawohl vonselbst. :-)  wobei ich wenn du ne (t)csh nimmst
ausserdem noch ne bourneshell (ash?) fuer scripte installieren wuerde,
csh ist naemlich nicht grade ne _scriptsprache_...

>- auf die Serielle umleitbar, termcap-faehig

 das ist unter MiNT auch kein so grosses problem...  (vorausgesetzt
die programme die du dann benutzt kennen auch termcap.)

 also, zusammenfassung:  wenn du MiNT dochnoch installierst dann kann
ich dir zB ne schoene pd kornshell empfehlen (benutz ich hier*), oder
tcsh ist anscheinend auch recht beliebt. :-)  ansonsten wuesste ich
nur die gnulib-bash...  (ok oder vielleicht noch irgendwelche
loehnware-shells, die sind aber meisstens so `schweinisch' programmiert
dass sie mit MiNT dann garnichtmehr laufen. :-(  und ausserdem bevorzuge
ich es zu meiner shell auch die source zu haben...)

*: ksh: die aktuelle version auf ftp.uni-paderborn.de hat ne macke,
also entweder warten bis das erledigt ist (thomas weiss bescheid :-)
oder mir mailen wer diffs fuer die aeltere
  @(#)PD KSH v4.7 92/08/12, MiNT release 0.6 as of Dec 23 1992, ts
haben moechte.  (oops, der Dec 23 ist das compilierdatum...)

 alle andern erwaehnten muessten auf atari.archive und diversen
`mirrors' rumliegen.

 hoffe es hilft, und gruesse vom weihnachtsmann :-)
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr

In <H.eg.d442ivog&oM@mips.ruessel.sub.org> naddy@mips.ruessel.sub.org (Christian Weisgerber) writes:

>Frank Bartels writes:

>> Mupfel aus der Gemini-Distribution, Version 1.21. Sehr empfehlenswert,
>> wenn man auf Kleinigkeiten verzichten kann.
>> Die tcsh in der Version 6.02. Gross aber fein.

>Die tcsh kenne ich von Unix her. *Wie* gross ist die denn auf dem ST?

 irgendwo hab ich ~300K im kopf...  (ksh hier ~200K).  unter MiNT mit
shared text liegt das textsegment dann allerdings auch nur einmal im
speicher...

>Fragt sich, ob ein derartiges Unix-Werkzeug auf einem Schrumpfrechner,
>wie dem ST, sinnvoll ist.

 wenn du was _vernuenftiges_ haben willst und eben keine
`moechtegern-shell' dann ganz bestimmt.  ok wenn der schrumpfrechner :-)
unter akutem RAM-mangel leidet... aber dann hattu eh verloren.

>> Koennen beide. Unter Filenameexpansion kann ich mir jetzt nicht richtig
>> vorstellen, was Du meinst.

>Das war mein missglueckter Versuch Filename Completion einzudeutschen.
>Kann Mupfel das auch? Ist fuer mich ein essentielles Feature.

 vergiss mupfel. IMHO. (jedenfalls die letzte version die ich gesehen hab...)

>Fragt sich auch ob, die jeweilige Shell das richtig kann: also auch
>z.B. ..\..\blaf_ expandieren

 ksh kanns, tcsh bestimmt auch.

>> >- sinnvolle Expansionsreihenfolge fuer Alias, History, Variablen und
>> >  brauchbare Quotierung
>> Scheint mir eher ein objektiver Aspekt zu sein. Besser selbst
>> ausprobieren. Das Quoten liegt in der Mupfel noch ein wenig im Argen,
>> doch die neueste Beta-Version verspricht Besserung.

>Ja, ich weiss warum ich frage. Mit dem Teil, das ich gerade benutze,
>kann ich z.B. nicht mehrere Befehle durch ';' getrennt in einen Alias
>packen, egal wie ich quote, ';' wird immer vor den Quotes ausgewertet.

 funktioniert bei ksh natuerlich auch richtig.

>> >- I/O-Umleitung, Pipes
>> Das ist wohl Standard. Es gibt ein pipe.ttp fuer tos, das aber in der
>> tcsh nicht funktioniert (can't make pipe). Abhilfe: MiNT

>Standard? Naja. Vielleicht hat es sich mit den letzten TOS-Versionen
>gebessert, aber die I/O-Umleitung lag beim ST schon immer im argen.
>Abstuerze, schlichtes Nicht-Funktionieren, kein EOF von einem Device...

 richtig, und ein grund mehr MiNT zu benutzen...

>Mit Pipes meine ich, dass sowas wie "lha l archiv | more" klappt. Das
>sollte so ablaufen, dass zuerst die Ausgabe in ein temporaeres File
>geleitet, danach die Eingabe aus diesem genommen wird. Nicht so ganz
>dasselbe wie unter Unix...

 abgesehen davon dass mit MiNT natuerlich auch richtige pipes
funktionieren (ach ;-) _koennte_ es sein dass die gnulib-bash sogar
sowas macht.

>> Tja, die Mupfel laeuft unter MiNT, kann aber keine Hintergrundprogramme
>> verwalten.

>Klar, wenn ich multitasken will, dann brauche ich MiNT. Ob ich das aber
>will, oder das auf einem ST ueberhaupt sinnvoll ist, das ist eine ganz
>andere Frage. Mir geht es im Moment nur um streng sequentielle Prozess-
>abarbeitung.

 naja ausser dem multitasking verbessert MiNT aber auchnoch einpaar
andere dinge... (beispiel s.o).  die mensch _ohne_ MiNT fuer ne
vernuenftige shell dann alle selbermachen bzw drumrumhacken muesste,
u.a. deswegen sind die wohl auch so selten (die shells).

>> Beide sind wohl eher gross, wenn man die Mupfel ohne Gemini aufruft, ist
>> es tragbar. Aber wer hat schon weniger als 2MB?

>Ich habe 4MB, aber ich moechte vermeiden, dass ich auf ein Szenario
>komme, wie:
>- 256kB-TOS im RAM (habe ich z.Zt.)
>- MiNT
>- Shell
>- oops, kein Platz mehr fuer gcc.
 :-)

 keinesorge, ich hab hier mit 4MB und MiNT + ksh + gcc 2.3.1 auchschon
news gelesen waehrend in hintergrund der make laeuft...

>> Version 1.5 testen. Gulam faellt aus, wegen hohem Alter, vieler Fehler
>> und Ballast (z.B. eigener Editor). Ausserdem unterstuetzt sie kein
>> shell_p (was das auch immer ist). Dadurch kann auf jeden Fall der nn an
>> die Shell Aufrufe schicken.

>Gulam hatte ich frueher einmal, ich habe auch nichts von neueren
>Versionen gehoert. Gulam ist arg instabil, grauselig dokumentiert
>(obwohl mir das heute vermutlich nicht mehr soviel ausmachen wuerde),
>und der ue taugt eh nichts, ist also wirklich ueberfluessig.

 gulam ist vielleicht sinnvoll fuer 512K kisten die unter staendiger
speicherknappheit leiden... aber sonst... tscha. :-)

>shell_p ist ein wirklich nettes Feature. Das ist ein Pointer der auf die
>Kommadozeilenauswertroutine der Shell zeigt. Die kann mit einer
>Kommandozeile als Parameter von einem Child-Prozess aufgerufen werden,
>und wird dann ausgefuehrt. Als system()-Aufruf bekannt.

 shell_p ist ein hack.  macht die shell ein malloc (bzw Malloc), gehoert
der speicher dem falschen process; macht einer mit system() was im
environment, betrifft das gleich alle statt nur den einen aufruf; etc. :-(
ausserdem ist auchnoch anscheinend nirgendwo festgelegt auf was fuer ne
shell shell_p zeigen soll (bourne? csh? command.com? ;-) sodass mensch
sich dann nichtmal bei der syntax sicher sein kann.

>Hatte ich vergessen zu erwaehnen, das sollte auch unterstuetzt werden.

 fuer die armen turboc binaries die ohne shell_p hilflos sind hab
ich hier noch so ein spezial-aufrufprogramm das dann bei bedarf ne
`richtige' shell startet... das reicht.  (hier grad erst geposted)

>> Bitte schreib mir Deine Erfahrungen! Was willst Du mit der Shell denn
>> anfangen? Ich benutze meine Shell ueberwigend fuer mein uucp-System und
>> kann es noch garnicht fassen, dass ich total mausfaul geworden bin! :-)

>Was man so alles mit einer Shell macht. Durch knapp sieben Jahre
>Konfrontation mit Ataris GEM und "benutzerfreundlichen" Programmen, ist
>mir ein Kommandozeileninterface einfach lieber. Fuer Hermes brauche ich
>sie natuerlich auch, ausserdem moechte ich Kleingkeiten einfach per
>Shell-Script erledigen lassen koennen. Ich sage nur grep, sed, awk

 eben, dann brauchst du MiNT und ne vernuenftige un*xshell, sonst macht
das keinen spass.

>(BTW, hat jemand ein brauchbares standalone-grep fuer den ST?),

 waer GNU grep brauchbar genug?

> sowas
>sagt mir nun mal mehr zu als klick-klick-Fenster-zerr-Menue-reiss-klick-
>verzweifel-weils-doch-nicht-geht-klick...

 jaa wem sagst du das...

 gruss,
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr