?Mir gefllt nicht, da gemsh.app in /bin und login.app in /usr/bin liegen 
 mssen. Geht das nicht auch anders
!Seit einigen Versionen sucht GEM-init (fr Experten: mittels shel_find() ) 
 die Programme mit Hilfe der AES-Environmentvariable $PATH. Diese setzt man 
 unter single AES in MINT.CNF, z.B.
setenv PATH .;C:\;u:\bin;u:\usr\bin;u:\usr\bin\GEM
 oder unter ATARI-AES 4.x in GEM.CNF, z.B.
setenv PATH=.,C:\,u:\bin,u:\usr\bin,u:\usr\bin\GEM
 oder unter N.AES in N_AES.CNF, z.B.
export PATH=.,C:\,u:\bin,u:\usr\bin,u:\usr\bin\GEM
In obigen Beispielen kann man z.B. init.app, getty.app, login.app und 
gemsh.app nach /usr/bin/GEM kopieren (mu man aber nicht). Man mu dann nur 
noch den Pfad zu getty.app in /etc/ttytab.gem und den Pfad zu boot.app in 
DESKTOP.INF bzw. NEWDESK.INF bzw. GEM.CNF bzw. N_AES.CNF anpassen.


?Mich strt, da unter AES 4.x zuerst die mit dem GEM.CNF-Befehl
 run zu startenden Programme ausgefhrt werden, dann erst die shell
!Man sollte bei einer GEM-init-Installation am besten berhaupt keine
 Programme per run aus *.CNF heraus starten. Erstens widerspricht dies dem 
 Konzept einer init suite, zweitens killt init.app dann sowieso gleich 
 alle parallel zu init.app laufenden GEM-Programme (ich wei auch nicht, 
 wie ich zwischen "run-Programmen" und berbleibseln aus der letzten 
 Sitzung unterscheiden kann).
 Abhilfe: s. nchste Frage


?Kann ich nach dem login auch benutzerabhngig Accessories und
 Applikationen starten
!Unter jedem AES 4.x kann man auch nachtrglich noch Accessories starten,
 allerdings werden diese unter GEM-init beim Ausloggen nicht beendet (ggf. 
 im logout script ~/.gemlogout killen). Man kann Accessories (und 
 Applikationen) benutzerspezifisch als Thing-Autostart anmelden, da Thing 
 $HOME auswertet.
 Alternativ kann man Accessories und Programme auch vom login batch der
 login shell ausfhren lassen, sofern /bin/loginsh oder /bin/loginsh.app 
 die login shell starten konnte und diese dann wie z.B. /bin/sh eine Datei 
 namens ~/.profile einliest. In ~/.profile schreibt man dann:

#!/bin/sh
# ~/.profile, this file will be read by /bin/sh when invoked as login shell
echo executing /home/root/.profile

cd /apps/PAINT/PAINT.APP
/apps/PAINT/PAINT.APP&
 
 Das cd ist	erforderlich, damit GEM-Programme ihre Resourcedatei finden. 
 Allerdings ist diese Methode nicht besonders sauber, da das Programm durch
 Pexec() statt shel_write() gestartet wird. Es mag auch nicht mit jedem AES
 4.x funktionieren.	Deshalb werden z.B. Accessories als Applikationen
 gestartet und werden unbrauchbar. Das &-Zeichen ist erforderlich, damit sh
 nicht blockiert wird.
 Besser ist dann schon ein spezielles Programm, wie z.B. x.gtp, welches
 GEM-init beiliegt. Es benutzt intern shel_write() (hoffe ich jedenfalls).
 Damit funktioniert dann auch der Start von Accessories:

x.gtp /boot/EYES.ACX


?Sehe ich das richtig, da ~/.gemlogin nur unter single AES eingelesen 
 wird
!Ja und nein. Einerseits wird ~/.gemlogin nur unter single AES direkt 
 eingelesen, andererseits kann und soll man diese Datei unter multi AES von 
 der login shell einlesen lassen, s. nchste Frage


?Ich mchte in ~/.profile nur dann GEM-Programme aufrufen, wenn ich mich 
 auch wirklich unter GEM einlogge, nicht aber wenn ich mich ber telnet, 
 modem, login oder sonstwie einlogge
!Einfach GEM-Programme aus ~/.gemlogin starten und diese Batchdatei nur 
 dann aufrufen, wenn eine bestimmte Environmentvariable wie z.B. $CLIPBRD, 
 die ausschlielich von login.app gesetzt wird, existiert. Beispiel fr 
 ~/.profile:

if [ ! $CLIPBRD ]
then
  echo "tty login..."
else
  echo "GEM login..."
  . $HOME/.gemlogin
fi

 Oder ~/.login fr die tcsh:

if ( $?CLIPBRD ) then
  echo "GEM login...";
  ~/.gemlogin;
else
  echo "tty login...";
endif


?Wenn ich in ~/.gemlogin GEM-Programme aufrufen will, dann aber nur unter 
 AES 4.x. Wie kann ich dies steuern
!Einfach .../GEM-init/usr/bin/aesversion aufrufen und exit status abfragen:

aesversion
if [ $? -ge 40 ]; then
  echo AES 4.x startup...
  x bubble.app
  x StartMeUp!.app
fi


?Wenn ich Thing in desktop.app umbenannt habe, meldet Thing beim Start: 
 "Startverzeichnis nicht gefunden."
!Thing sucht nach thing.app im aktuellen Verzeichnis. Daher entweder 
 desktop.app als _Kopie_ von thing.app anlegen, oder thing.app nur nach 
 desktop.app linken, oder thing.app in desktop.app umbenennen und im 
 gleichen Verzeichnis eine leere Datei namens thing.app anlegen (die sich 
 natrlich nicht starten lt...)


?Wenn /bin/loginsh gestartet wird und ich MiniWin benutze, erscheinen in
 dem Applikationsmen von N.AES die Eintrge "  LOGINSH" und "  LOGINSH &".
 Ist das in Ordnung.
!Keine Panik - das ist ok. N.AES erkennt zum Glck, wenn ein Programm fork
 & exec aufruft. "  LOGINSH" ist daher /bin/loginsh und "  LOGINSH &" die
 parallel laufende (geforkte) login shell gem. /etc/passwd


?Bei login.app erscheint seit neueren Versionen kein password-Dialog mehr
!Wahrscheinlich hat login.app eine falsche, d.h. alte, Resourcedatei
 geladen. Bitte beachten: wer $NLSPATH bzw. /usr/share/locale/xy/RSC/
 installiert hat, sollte auch die dort abgelegten Resourcedateien bei einem
 Versionswechsel erneuern. Sie werden nmlich bevorzugt aus den
 NLS-Verzeichnissen geladen. Setzen Sie in N_AES.CNF doch mal language auf
 2 oder 0 oder 5 und loggen sich neu ein...


?Wie logge ich mich denn unter GEM-init aus
!Unter single AES und ATARI AES 4.x indem man entweder den Desktop oder, 
 falls man keinen Desktop aktiviert hat und in gemsh gelandet ist, indem 
 man gemsh beendet.
 Hlt man beim Beenden des Desktops irgendeine der Tasten Rechts-Shift,
 Links-Shift, Alternate oder Control gedrckt, landet man in gemsh
 Unter AES N.AES gibt es folgende Mglichkeiten:
 1. man starte das Programm (/usr/bin/GEM/_logout.app)
    (Empfehlung: in das "Tools"-Men von Thing aufnehmen)
 2. sofern die bash die login shell ist, kann man _logout.app auch in 
    ~/.bash_logout aufrufen, s. Beispiel im Beispiel-Home-Verzeichnis 
    dieses Archives, und die bash durch Eingabe von logout oder Ctrl-D 
    beenden
 3. ganz brutale Leute knnen gemsh.app auch ein SIGTERM schicken bzw. 
    /proc/gemsh.* auf das Mlltonen-Icon ziehen (sauber ist das aber 
    nicht...)


?Ich habe die Hinweise mit terminal.app, messages und CONSOLE.TTP nicht
 ganz verstanden
!CONSOLE.TTP ist ein Programm von Karsten Isakovic, welches
 GEMDOS-Bildschirmausgaben, die normalerweise auf den GEM-Bildschirm
 "geschmiert" wrden, abfngt.
 Kandidaten fr solche "Schmierereien" sind z.B. Dmon-Programme wie der
 syslogd oder pppd. Fr die Benutzung unter GEM-init mu CONSOLE.TTP in
 /bin/messages umgetauft werden. Ist allgemeiner.
 Da MiniWin-Fenster immer in der gleichen Gre geffnet werden, ist es
 zweckmig, eine Kopie von  MiniWin in /bin abzulegen, mit eigens
 angelegtem /bin/MINIWIN.CNF, in der die fr messages gewnschte
 Fenstergre gesichert wird.
 Damit man fr /bin/messages nicht unbedingt /bin/MINIWIN.APP benutzen mu,
 sucht init.app unter AES 4.x nach einem Programm mit dem allgemeinen Namen
 /bin/terminal.app und bergibt ihm den Parameter u:\bin\messages.
 init.app ist jedoch nicht zwingend auf /bin/terminal.app angewiesen.
 Existiert dieses Programm nicht, wird der normale AES-Aufruf zum Start
 von TOS-Programmen (shel_write()) benutzt.
 Wird unter AES 4.x /proc/messages.* gefunden, schreibt GEM-init selber
 einige Meldungen in das messages-Fenster.


?Kann ich eigentlich KGMD-/MINTOS 1.4.x-init und GEM-init gemeinsam
 benutzen
!Ja, es gibt mehrere Varianten:
 1.1 init in MiNT.Cnf anmelden: INIT=u:\usr\sbin\init
 1.2 in die console einloggen, d.h. in /etc/ttytab eintragen:
     console "/usr/sbin/getty console" vt52 on secure
 1.3 nachdem Einloggen (am besten als root) von der login shell aus GEM
     starten: z.B. /usr/lib/n_aes.sys, vielleicht geht auch
     exec /usr/lib/n_aes.sys
 1.4 GEM-init wie beschrieben installieren

 2.1 init in MiNT.Cnf anmelden: INIT=u:\usr\sbin\init
 2.2 AES als getty fr die console anmelden, d.h. in /etc/ttytab eintragen:
     console "/usr/etc/execmtos" vt52 on secure
     Achtung: zu diesem Zweck mu N.AES /usr/multitos/gem.sys heien
 2.3 GEM-init wie beschrieben installieren

 3.1 GEM in MiNT.Cnf anmelden, INIT-Programm wegkommentieren, Boot-Scripte
     von z.B. von MiNT.Cnf aus starten:
     #INIT=u:\usr\sbin\init
     exec u:\bin\sh /etc/rc
     GEM=u:\usr\lib\n_aes.sys
 3.2 GEM-init wie beschrieben installieren


?Warum stehen die Programmflags von init.app, getty.app, login.app und
 gemsh.app auf ST-RAM
!Diese Programme sind in keinster Weise auf ein Geschwindigkeit angewiesen.
 Das TT-RAM ist mir zu schade, um es an hauptschlich nur wartende
 Programme zu vergeben. Es ist empfehlenswert, auch bestimmte andere
 Dmonen, wie z.B. den syslogd, crond, lpd ins ST-RAM zu laden


?Ich habe mir die bash als login shell eingerichtet. Will ich eine zweite
 bash laufen lassen, starte ich einfach nochmal /bin/loginsh. Doch dann 
 werden alle mglichen GEM-Programme, die ich in ~/.profile hochfahre, ein 
 zweites Mal gestartet. In ~/.profile rufe ich jedoch auch Befehle auf, die 
 bei jedem Shellstart ausgefhrt werden sollen. Was tun
!Ganz einfach, die bash ganz normal starten. Dann wird nur ~/.bashrc
 eingelesen.
 Tip: in Thing im Men " Tools " die Menpunkte "  Shell" (/bin/bash
      starten) und "  Login Shell" (tw-call.app ohne Parameter starten)
      einrichten


?Warum sind die Programmdateien von GEM-init so gro
!GEM-init benutzt eine POSIX-Lib mit MiNT-Emulation fr plain TOS und
 u.a. "locale"-Funktionen und -Strings, die fr de, en, fr und nl
 implementiert sind.

?Ich habe boot.app wie unter Punkt installation beschrieben nach
 u:\usr\sbin (liegt auf einem Minix-Filesystem) kopiert und als
 GEM-Autostart-Programm angemeldet. Nach dem Booten meldet GEM bei
 BOOT.APP: "Objekt gleichen Namens schon vorhanden bzw. besitzt "nur
 Lesen"-Status."
!boot.app steht wahrscheinlich auf rw-rw-rw- statt rwxrwx--x. Dies passiert
 z.B. wenn man Dateien mit x-Flag mit dem ROM-Desktop oder GEMINI kopiert


?Was bedeuten die Schrgstriche in dem Dateinamen /etc/passwd
!Der Schrgstrich oder slash ist unter UNIX das Pendant zum backslash des
 GEMDOS. Unter UNIX gibt es keine Laufwerksbezeichnungen. Das
 Wurzelverzeichnis wird dadurch dargestellt, da ein Pfad mit einem / 
 beginnt. Unter MiNT wird das Wurzelverzeichnis / zu u:\, soda /etc/passwd 
 gleichbedeutend mit u:\etc\passwd ist


?Direkt nach dem Einloggen kommt die Meldung "Diese Anwendung kann das
 angegebene Objekt nicht finden."
!Die login shell (oder ~/.gemlogin unter single AES) wurde nicht gefunden


?Ich habe mich als non-root eingeloggt und beim Versuch bestimmte Dateien
 zu ffnen, kommt ein Alert mit "Zugriff verweigert."
!Die Dateiattribute sind z.B. auf rw-rw---- gesetzt. Das lt sich mit
 einem Aufruf eines UNIX-kompatiblen ls.ttp mit dem Parameter -l
 feststellen. Leider zeigt nicht jeder Desktop diese Attribute an


?Was heit denn eigentlich non-root
!Ein "normaler" User, mit eingeschrnkten Rechten


?Warum kann ich nur einen alternativen Desktop starten, wieso nicht den
 ATARI-Desktop
!Weil ich nicht wei, wie ich den Desktop im ROM oder innerhalb
 GEM.SYS erstens aufrufen und zweitens auch wieder beenden kann


?Ich habe mich als non-root eingeloggt. Ich kann mir dann zwar den Inhalt
 bestimmter Verzeichnisse anschauen, die darin enthaltenen Dateien und
 Unterverzeichnisse jedoch nicht ffnen, obwohl sie den Status rw-rw-rw
 besitzen
!In diesem Fall hat das betreffende Verzeichnis das x-Flag nicht gesetzt,
 also z.B. nur drwxrw-r-- statt drwxrwxr-x


?Warum kann ich init.app nicht in der Zeile INIT= in MiNT.Cnf eintragen
!INIT= ist nur fr TOS/TTP-Programme (oder ausfhrbare Versionen von GEM
 selber) gedacht


?Wofr steht eigentlich das Zeichen "~" bei manchen Dateinamen
!Fr das HOME-Verzeichnis


?Was ist das HOME-Verzeichnis
!Das HOME-Verzeichnis wird in /etc/passwd fr jeden Benutzer individuell
 eingestellt, z.B. /home/root oder /home/guest. Es enthlt allerlei
 benutzerspezifische Dateien wie Shell-Scripts, Info-Dateien von modernen
 GEM-Programmen, etc.


?Ich habe mich als non-root eingeloggt und kann auf Laufwerk C: pltzlich
 keine Programme mehr starten
!Das liegt wahrscheinlich daran, da C: eine GEMDOS-Partition ist. Diese
 gehrt seit neueren MiNT-Versionen der root (mit rw-rw----). Dies wurde
 eingefhrt, weil das GEMDOS-Dateisystem keinerlei Multiuserverwaltung
 und damit keinerlei "Sicherheit" bietet. Abhilfe, wenn's denn unbedingt
 sein mu: exec u:\bin\chmod -v 666 u:\c in MiNT.Cnf einfgen


?Wenn ich init.app unter MiNT und AES 3.x starte, strzt login.app nach der 
 Eingabe des Pawortes mit einer memory violation ab
!Ist mir auch schon passiert. Der Grund ist aber darin zu suchen, da
 SingleAES nicht unter MiNT, sondern nur unter MiNTnp luft


?Es gibt doch auch init, getty, login und sh als TTP-Programme fr MiNT.
 Warum kann man nicht diese Programme zum Einloggen benutzen
!Das geht nur dann gut, wenn man sich als root einloggt. Sobald man sich
 mit diesem init-Paket als non-root einloggt, bekommt man grte
 Schwierigkeiten, wenn GEM auf Info-Dateien und Fonts auf GEMDOS-Partitions
 (sofern diese root-only sind) zugreifen will. Es kann dann z.B. passieren,
 da man nur noch "weie Zeichen auf weiem Grund" sieht. Auerdem kann man
 sich nur einmal einloggen, da sich GEM normalerweise nicht beenden lt...

