🚀 go-pugleaf

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