1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. In diesem Bereich findet ihr Tutorials und Reviews. Die Forenrechte zur Erstellung neuer Themen sind hier eingeschränkt, da Problemdiskussionen bitte in den übrigen Forenbereichen auf Apfeltalk zu führen sind. Wer ein Tutorial oder Review einstellen möchte, kann im Unterforum "Einreichung neuer Tutorials" ein neues Thema erstellen. Die Moderatoren verschieben den Beitrag dann in den passenden Bereich.
    Information ausblenden

[TUTORIAL] Terminal - Teil 3

Dieses Thema im Forum "Software-Tutorials" wurde erstellt von Hobbes_, 10.04.07.

  1. Hobbes_

    Hobbes_ Gast

    Dies ist Teil 3 eines Tutorials zu Terminal

    Inhalt
    Teil 1
    (0) Einleitung
    (1) Das Programm
    (2) Unix als System
    (3) man
    (4) Einige Befehle

    Teil 2
    (5) I/O-Redirection / Pipes und Wildcards / Regular Expressions
    (6) Editoren vi/vim, Emacs und nano
    (7) "Pimp my Terminal"

    Teil 3
    (7) "Pimp my Terminal" (Fortsetzung)
    (8) User / Admin / Superuser

    Teil 4
    (8) User / Admin / Superuser (Fortsetzung)
    (9) Wie komme ich zu UNIX-Programmen?

    Teil 5
    (9) Wie komme ich zu UNIX-Programmen? (Fortsetzung)

    Teil 6
    (10) Einige Unterschiede zwischen Darwin und anderen UNICES
    (11) Weitere Informationen / Referenzen / Links
    Dank

    ------

    (7) "Pimp my Terminal" (Fortsetzung)

    (7.3) bash
    Auf die Standardshell des aktuellen Mac OS gehen wir etwas ausführlicher ein. UNIX hat ja nicht gerade das Problem, dass man es zuwenig konfigurieren könnte. :) So sehen wir uns hier nur auf ein paar Dinge an, welche auch schon zu Beginn hilfreich sein könnten. Gerade zu bash finden sich im Internet ausführliche Informationen (zB. hier).

    Lernen wir ein paar seiner Shortcuts im interaktiven Modus kennen:
    • Pfeil links = ctrl-b : Cursor ein Zeichen nach links
    • Pfeil rechts = ctrl-f : Cursor ein Zeichen nach rechts
    • esc-b : Cursor ein Wort nach links
    • esc-f : Cursor ein Wort nach rechts
    • ctrl-a : Zeilenanfang
    • ctrl-e : Zeilenende
    • ctrl-k : löschen bis ans Zeilenende
    • ctrl-u : ganze Zeile löschen
    • ctrl-t : twiddle - tauscht das Zeichen links des Cursors und unter dem Cursor
    • ctrl-c : laufendes Programm stoppen
    • ctrl-d : aktuelle Shell beenden (enspricht logout bzw. exit)
    • Pfeil oben = ctrl-p : vorheriges Kommando (Befehls-History)
    • Pfeil unten = ctrl-n : nächstes Kommando (Befehls-History)
    • ctrl-r : Befehl suchen rückwärts
    • ctrl-R : Befehl in History rückwärts (mehrere Befehle)
    • ctrl-z : aktuelles Programm in den Hintergrund schicken (suspend); man kann es von der Shell später wieder mittels fg bzwl fg <Nummer> in den Vordergrund holen; Der Befehl jobs zeigt uns die Nummer).

    (7.3.1) bash Prompt
    Zahlreiche Informationen zur Konfiguration der Shell sind in Umgebungsvariablen festgehalten.
    Das Aussehen des Prompts ist in der Umgebungsvariable PS1 der Shell gespeichert. Wir können uns diese Umgebungsvariablen ansehen mittels des Befehls
    $ set
    und finden dabei auch die Definition der Variable PS1. Diese kann beispielsweise so aussehen
    PS1='\h:\w \u\$ '​

    Diese Formatierung bewirkt den folgenden Prompt:
    Computername:Verzeichnis Benutzer$​

    Der Prompt kann sehr frei definiert werden. Als nun routinierte Shell-Benutzer fällt es uns ja nicht mehr schwer, uns die Informationen mittels man selbst zu beschaffen. :)

    $ man bash
    dann eingeben:
    /prompting (für Suche 'prompting')
    n (nächste Fundstelle; dann sind wir dort, wo wir hin wollten)​

    So sehen wir nun alle Informationen zur Konfiguration des Prompts. Einige wichtige habe ich ausgewählt. Schauen wir uns die Definition unseres Beispiels nochmals an. Unten stehen die Erklärungen:

    PS1='\h:\w \u\$ '

    \h Hostname bis zum ersten .
    \w aktuelles Arbeitsverzeichnis
    \u Benutzername des aktuellen Benutzers
    \$ #bei UID 0 (Superuser), sonst $

    Einzelne weitere interessante Parameter
    \! History-Nummer
    \# Befehlsnummer

    Der neue Prompt wird mittels des Befehls export gesetzt und bekanntgemacht. Beispiel:
    $ export PS1='[\!] \h:\w \u\$ '

    Zahlreiche Beispiele finden sich hier: Beispiele, Beispiele, Beispiele, Beispiele

    Information: Der standardmässig eingestellte Prompt beinhaltet bereits die wichtigsten Informationen in guter Darstellung. So gibt es eigentlich keinen zwingenden Grund, diesen anpassen zu müssen. Für fortgeschrittene Benutzer kann es sich jedoch beispielsweise lohnen, für Admin-Accounts andere Farben zu definieren, so dass immer klar ist, ob man in einem User- oder Admin-Account arbeitet...

    Dieser innerhalb der Shell definierte Prompt verschwindet nach Ende der Shell wieder. Dies hat auch den Vorteil, dass wir einen Fehler rasch rückgängig machen können.
    Deshalb funktioniert auch folgende Notfall-Info: Wir geben einfach exit auf einer neuen Zeile ein und schliessen das Terminal-Fenster. Beim Neustart der Shell kommt wieder der Standard-Prompt.

    Später sehen wir, wie wir die Shell bleibend konfigurieren. Da sieht es dann schon anders aus.


    (7.3.2) alias
    Dieser Befehl ist ausserordentlich nützlich. Er erlaubt es uns neue Befehle zu definieren. Weiter oben erklärten wir, dass eine gewisse Sicherheitsfunktion uns vor versehentlichem Überschreiben schützen kann bei Befehl cp (kopieren). Wir können den Befehl cp nun auch so definieren, dass er automatisch immer diesen Parameter dazufügt.

    $ alias cp=’cp -i’

    Probiere mit dieser Funktion mal eine Datei zweimal an denselben Ort zu kopieren...

    Mit folgendem Befehl können wir uns alle Definitionen ansehen:
    $ alias

    Auch diese Definitionen verfliegen wieder, sobald wir uns aus der Shell ausloggen. So wollen wir uns doch mal ansehen, dass wir ein paar Dinge definitiv konfigurieren können...


    (7.3.3) bash - Konfiguration
    bash sucht sich seine Informationen an verschiedenen Stellen zusammen. Es gibt

    1) Systemweit geltende Informationen (vordefiniert oder allenfalls modifiziert durch den Admin)
    /etc/profile
    /etc/bashrc ​

    2) Benutzerspezifische Dateien
    ~/.bash_profile bzw. ~/.bash_login bzw. ~/.profile (nicht bash-spezifisch)
    ~/.bashrc​

    Konzept: Dabei unterscheidet bash, wie gestartet wurde. Kurz und vereinfacht:
    • Wenn die Shell direkt von Terminal aufgerufen wird (Login-Modus), so werden /etc/profile (unspezifisch; welches jedoch von sich aus /etc/bashrc aufruft) und dann ~/.bash_profile bzw. ~/.bash_login bzw. ~/.profile aufgerufen (je nachdem, welches zuerst gefunden wird). Optimalerweise sind auch diese Scripts so gestaltet, dass sie die persönliche bashrc-Datei ~/.bashrc aufrufen, so dass die Konfiguration vollständig ist.
    • Wenn bash direkt vom Benutzer aus einer Shell heraus gestartet wird (interaktiver Modus)
      $ bash
      so werden nur /etc/bashrc und ~/.bashrc ausgeführt.

    Ganz einfach :)

    Wir werden es mit folgenden Beispielen leichter verstehen. Auch fortgeschrittene User sollten nur die Dateien im persönlichen Verzeichnis zu ändern. Diese können im schlimmsten Fall ohne Probleme einfach wieder gelöscht werden. Bei Fehlern in den Systemdateien in /etc kann das System unter umständen in einen nicht mehr boot-fähigen Zustand geschossen werden...
    Auch müssen wir uns so nicht als Admin anmelden (was wir ja gar noch nicht gelernt haben :innocent: ). Aber wir können uns die systemweiten Konfigurationsdateien ja trotzdem mal ansehen:
    $ less /etc/profile

    $ less /etc/bashrc

    Wir sehen echte Shell-Scripts. Scripts sind kurz gesagt eine Abfolge von Befehlen. Auf die Syntax gehen wir im Moment nicht ein. Wir erkennen jedoch in /etc/profile, dass irgendwo /etc/bashrc aufgerufen wird. In /etc/bashrc erkennen wir, wie der Prompt definiert wird.

    Bevor wir unsere eigenen Konfigurationsdateien definieren und so die ersten Shell-Scripts schreiben werden, muss ich noch etwas beichten :eek: :
    Bisher haben wir einen wichtigen Punkt unterschlagen. Unsere Shell kann noch nicht korrekt mit Umlauten umgehen. Sie wird nicht automatisch mit der Installation des Mac OS internationalisiert. Aus didaktischen Gründen haben wir dies bisher weggelassen. Jetzt werden wir das korrigieren...

    Beispiele:
    So findet sich auf der Harddisk, sozusagen im Basisverzeichnis / ein Link mit dem Namen 'Benutzerhandbücher und Informationen'. Schauen wir doch nochmals
    $ ls –la /

    Anstelle des Umlauts stehen nur zwei Fragezeichen. Dies können wir zwar mit der Option –w bei ls korrigieren:
    $ ls –law /

    Jedoch besteht das Problem auch, wenn wir eine Datei mit Umlauten schreiben wollen:

    $ touch ~/jöö.txt
    $ touch ~/ähm.txt
    $ ls –law ~


    Die Umlaute werden nicht korrekt generiert. Wir können das auch im Finder in unserem Benutzerverzeichnis kontrollieren...

    Dies werden wir nun unter anderem korrigieren. Die Beispiele sind dabei an Scripts angelehnt isnbesondere zur Internationalisierung, wie sie bereits früher in Apfeltalk beschrieben wurden (man muss ja nicht immer alles neu erfinden, Link (MacMark)).

    Generieren wir mal unsere eigenen einfachen Scripts. Wir benutzen dazu simpel nano (oder Könner bereits vim, der sich ja sowieso zu lernen lohnt) und speichern das Ganze. Selbstverständlich können wir dazu auch copy & paste benutzen :)

    $ nano ~/.bash_profile

    Code:
    . .bashrc
    export PS1='\h:\w \u\$ '
    alias ls='ls -w'
    pman() { man -t "$@" | open -f -a Preview; }
    
    Zeilenweise Erklärung:
    1) Das zusätzliche Shell-Script .bashrc wird gestartet. Dies erfolgt mit dem Punkt am Zeilenanfang (ein kurzer aber mächtiger Befehl :) ).
    2) Wir definieren unseren Prompt nach Wunsch.
    3) Alias definieren unsere Zusatzfunktionen. Dabei benutzen wir auch schon die Option –w für ls. Weitere können nach belieben definiert werden.
    4) Definition einer Shell-Function: pman kann aufgerufen werden wie man. Der neue Befehl generiert dann jedoch direkt ein PDF (man für Ästheten); von pepi
    Wenn wir diese Datei gespeichert haben, editieren wir die nächste:
    $ nano ~/.bashrc

    Code:
    export LC_ALL=de_DE.UTF-8
    
    export LANG=de_DE.UTF-8
    Wir erinnern uns, dass wir das Terminalprogramm ebenso auf UTF-8 eingestellte haben.

    Als nächstes benutzen wir noch eine weitere Definitionsdatei von bash, um auch noch die letzten Konfigurationen vorzunehmen:

    $ nano ~/.inputrc

    Code:
    set meta-flag on
    set convert-meta off
    set output-meta on
    set completion-ignore-case on
    set show-all-if-ambiguous on
    Die Erklärungen zu diesen Schaltern finden sich hier. Dies zeigt auch, dass man noch viel konfigurieren könnte...


    So, jetzt haben wir viel eingestellt. Insbesondere haben wir unser System auf deutsch internationalisiert. Eigentlich haben wir uns eine Pause verdient – und so auch der Computer. Schliessen wir die Shell
    $ exit
    und schliessen wir das Terminal-Fenster.



    Schon zurück?
    Nach der Pause können wir nun eine neue Shell öffnen. Dies müssen wir übrigens auch tun, wenn wir direkt ohne Pause durchgearbeitet haben. ;) Die oben gemachten Änderungen funktionieren erst ab dem neuen Start der Shell. Wir erinnern uns: Es sind Scripts, die zu bestimmten Zeitpunkten ausgeführt werden.

    So könnte man übrigens auch ein Script definieren, das beim Verlassen der Shell ausgeführt wird. Wir müssen es in ~/.bash_logout speichern. Doch das lassen wir für den Moment.


    (7.3.4) bash - Scripts
    Bereits im Rahmen der Konfiguration erwähnten wir oftmals Scripts. Scripts sind eine Abfolge von Befehlen, die zur einfacheren wiederkehrenden Anwendung derselben in einer Textdatei zusammengefasst werden. Dazu können mittels spezifischer Konstrukte bedingte Ausführung (if...fi), repetitive Anwendungen (Schleifen) und auch weitere Sprachelemente zur Ablaufsteuerung verwendet werden. Diese Befehlsabfolge kann dann wie ein einzelnes Programm aufgerufen werden.
    Shell-Scripts sind wirklich das Salz in der UNIX-Suppe. Ohne sie läuft schlichtweg nichts. Mit etwas Erfahrung anderer Programmiersprachen lassen sich die verschiedenen Scriptsprachen zwar leicht aneignen. Dennoch sei zur Vorsicht gemahnt, da die Syntax oft in kleinen jedoch entscheidenden Details unterschiedlich ist.
    Das Internet ist voll mit Beispielen zu Scripts (Suchfunktion). Auch gibt es einige sehr gute Informationen (hier und hier), welche den Umfang dieses Tutorials bei weitem sprengen würden. Ebenso empfehlen sich einige Bücher.


    (7.4) tcsh
    Bis Mac OS 10.2 war die tcsh (klassische BSD-Unix-Shell) die Standard-Shell. Der grösste Hauptunterschied zu einer sh-kompatiblen Shell wie bash ist die Script-Sprache. Diese ist sehr nahe an C angelehnt - und damit nicht mehr kompatibel zu beiden. Dies bringt jedoch Vorteile, wenn sich jemand sowieso gewohnt ist, C-Programme zu schreiben.

    Daneben bietet die Shell einigen Benutzerkomfort. Sie hat einen command line editor, der mit dem gleichen Befehlssatz wie vi bedient werden kann. Auto-Vervollständigung von Programmen und Dateinamen (Tabulator) können Geschwindigkeitsvorteile bringen. Eine Rechtschreibprüfung (Korrektur zb. des Befehls lz nach ls) kann ebenso Vorteile bringen. Andererseits können solche Eingabehilfen auch rasch Probleme mit sich bringen, wenn (trotz Sicherheitsnachfrage nach automatischer Korrektur) ein Befehl oder eine Datei halt doch falsch durch das System substituiert wurde. Diese sehr mächtigen Zusatzfunktionen sind also eher etwas für fortgeschrittene Benutzer.

    Ansonsten kann die Shell recht ähnlich wie bash in eigenen Konfigurationsskripten (andere Namen) konfiguriert werden. Ich verweise aufgrund des Umfangs in diesem Kontext auf das ausführliche Manual (man tcsh / oder wer oben für bash in .bash_profile bereits pman definiert hat (Danke pepi), kann in bash das ganze noch ästhetischer ansehen mittels pman tcsh).

    Der Wechsel von tcsh auf bash erfolgte wahrscheinlich hauptsächlich wegen der ausserodentlich weiten Verbreitung von bash im Bereich der Linux-Welt.

    (Anmerkung: Da Scripts in der ersten Zeile optimal direkt angeben, mit welcher Shell sie ausgeführt werden [she-bang], können ohne Probleme sh- bzw. csh-kompatible Scripts ausgeführt werden. Andererseits gibt es eher Probleme, wenn Scripts versionen-spezifische Features einer Shell verwenden. Diese werden nicht direkt durch die Shell abgefangen, sondern müssen durch den Programmierer abgefangen werden.)


    (7.5) Perl / Python / andere Programmiersprachen
    Scripts / Programme müssen nicht nicht unbedingt in einer Shell-spezifische Sprache geschrieben werden. Es können auch echte Programmiersprachen wie Perl und Python (benannt nach Monty Python) verwendet werden. Diese sind viel mächtiger an Funktionalität und bieten so mehr Möglichkeiten.
    Systemprogramme werden dann jeweils an passender Stelle aus dem Programm heraus aufgerufen, so dass sich auch mit ihnen die gleiche Funktionalität wie in Shell-Sprachen erzielen lässt. Letztlich kommt es auf die Komplexität des Problems und die Kenntnisse des Entwicklers an, welche Sprache in welchem Ausmass verwendet wird.

    Zu Perl habe ich von etinzi und Skeeve einen Link auf ein ausführliches Tutorial erhalten: Link. Auch hat sich Skeeve bereit erklärt, dass man sich bei Perl-spezifischen Fragen gern an ihn wenden kann. Vielen Dank!


    (8) User / Admin / Superuser (meist = root)
    Wie im ersten Teil dieses Tutorials gesehen (Kapitel 2.2), wird klar zwischen diesen Benutzerkategorien unterschieden. Die für normale User vergebenen Rechte genügen für das alltägliche Arbeiten, schützen jedoch andere Benutzer und insbesondere das System vor schädlichen Einflüssen. Einige Konfigurationen (Programme für alle Benutzer freigeben) müssen jedoch als Superuser ausgeführt werden. Der Superuser wird auf Macs immer root genannt. In anderen Systemen heisst er meist auch so (muss jedoch nicht).

    Wir sind ja mittlerweile schon etwas geübt im Umgang mit unserer Shell. Nichtsdestoweniger muss nochmals ein Warnschild hier hin:
    Dies gilt insbesondere, wenn wir als Admin oder gar Superuser unterwegs sind.

    Kommentar: Mac OS ist so konfiguriert, dass man das Passwort für root selbst gar nicht benötigt. Standardmässig ist root auch deaktiviert (unmöglicher Passwort-Hash). Das Ganze funktioniert - wie wir sehen werden - wesentlich eleganter und besser geschützt. Dieses Vorenthalten des root Passworts ist eine hervorragende Idee für einen Computer, der doch hauptsächlich von Personen benutzt wird, welche v.a. die grafische Benutzeroberfläche benutzen und mit UNIX sonst nicht zwingend Kontakt hatten.
    Die Sicherheit des Systems hängt stark von der Sicherheit dieses Passwortes ab. Wieso soll man vom Benutzer, welcher den Computer erst gerade auspackte, bereits so eine schwierige und - wie wir sehen werden - unnötige Frage stellen?

    Mit zunehmender Kenntnis im Umgang mit UNIX wirst Du sehen, dass es für viele Fragen zahlreiche Lösungswege gibt. So gibt es gerade im Umgang mit den im folgenden beschriebenen Bereichen verschiedene Lösungsmöglichkeiten. Ich habe eine Form gewählt, die so sicher funktioniert und es mir gleichzeitig erlaubt, einige weitere Punkte zu beleuchten.


    (8.1) sudo – Ein Entfesslungskünstler, von Houdinis Klasse
    Dieses Programm ist die Antwort auf die Frage: Wie kann ich Programme mit den Rechten eines anderen Benutzers (v.a. Superusers) starten, wenn ich nicht mal deren Passwort kenne. Damit kann die Zeitdauer, während der effektiv der Superuser aktiv ist, auf ein Minimum reduziert werden. Ausserdem kann man so Personen das Rechte geben, gewisse administrative Aufgaben auszuführen ("rollenbasierte Administration"), ohne dass man ihnen gleich ein geheimes Passwort geben muss (das man bei Vertrauensbruch wieder bei allen anderen Administratoren ersetzen muss). Die Authentifikation erfolgt nämlich nicht über ein zentrales root Passwort, sondern über das benutzereigene Passwort (das selbstverständlich wie jedes Passwort auch sicher gewählt werden muss).

    sudo ist ein Akronym für 'substitute user do' (führe einen Befehl als anderen Benutzer aus)

    Probieren wir es mal aus mit einem gefahrlosen Befehl.
    $ sudo ls

    sudo fragt nach einem Passwort. Dies ist Dein persönliches Passwort und hat nichts mit dem Passwort von root zu tun. Dieses Passwort werden wir nie brauchen.

    Es gibt nun zwei Möglichkeiten
    1. Wenn jetzt das aktuelle Verzeichnis ausgegeben wurde, dann geschah dies mit root Rechten. Dann ist auch klar, dass Du entweder (a) von einem Mac-Account aus die Shell eröffnet hast, der Admin-Rechte hat (dies ist standardmässig eigentlich nicht empfehlenswert; man sollte grundsätzlich immer vom gewöhnlichen Benutzer-Account aus arbeiten) oder dass Du (b) die entsprechenden Konfigurationsdateien von sudo bereits angepasst hast (also ein Pro, der die nächsten Abschnitte überspringen darf :) ).
    2. Eigentlich war zu erwarten, dass sudo das Passwort nicht akzeptiert, noch zweimal nachfragt und dann letztlich mit folgender Fehlermeldung den Dienst quittiert: User is not in the sudoers file. This incident will be reported.

    sudo verfügt über einen ausgeklügelten Schutzmechanismus, mit dem präzise definiert werden kann, wer was mittels sudo machen kann. Es wäre ja noch zu schön, wenn jeder Benutzer (zB. gar ein Gast) mittels sudo Programme mit root Rechten ausführen könnte...

    Standardmässig haben normale Benutzer also nicht das Recht, sudo zu benutzen. Andererseits haben alle mit Administrationsrechten ausgestatten Mac User das Recht, sudo ohne Einschränkung zu benutzen.

    Wir werden diesen Schutzmechanismus im Verlauf genauer ansehen. Auch dieser Mechanismus kann präzise eingestellt werden. Jedoch benötigt man dazu root Rechte, die es erstmal zu erlangen gilt :)

    Anmerkung: sudo kann nicht nur ein Programm als root ausführen. Man kann mittels der Option -u (siehe einmal mehr man sudo :) ) auch einen beliebigen anderen Benutzer wählen. Das einzugebende Passwort bleibt jedoch das eigene.


    Link: Fortsetzung Teil 4
     
    #1 Hobbes_, 10.04.07
    Zuletzt von einem Moderator bearbeitet: 04.11.09
  2. Tengu

    Tengu Apfel der Erkenntnis

    Dabei seit:
    05.02.07
    Beiträge:
    721
    Mir ist noch ein Terminal Pimp begegnet...

    Eterm
    http://www.eterm.org/

    Das x11 Terminal muss ja nicht immer zurückstehen. Es gibt dazu einen Fink-Port. Jedoch sollte man sich auf Grund der riesigen Vielzahl an Optionen einen Alias setzen.

    Dann gibts einen Window Manager, der besonders ist:
    ion

    Auch dazu gibt es ein Fink Package...:
    http://de.wikipedia.org/wiki/Ion_(Windowmanager))

    Der für Terminalogen wohl ziemlich nett, auch X11 lastig.

    Viel Spaß damit,
    Gruß,
    Mark
     
    #2 Tengu, 05.05.07
    Zuletzt bearbeitet: 05.05.07
  3. Hobbes_

    Hobbes_ Gast

    Vielen Dank für die Links!
     
  4. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    Als Ergänzung zu Punkt 7.3 möchte ich folgendes einbringen, daß sich ein Großteil der genannten Tastenkürzel in so gut wie allen Cocoa Applikationen verwenden lassen.

    Das bedeutet man kann beispielsweise das sehr praktische ^T auch in Mail, Safari, oder TextEdit genauso wie in iChat und Adium verwenden um die Buchstaben rechts und links von der Einfügemarke zu vertauschen. Somit läßt sich schnell und einfach der klassische Buchstaben- oder Zahlendreher in sehr vielen Applikationen ausbessern.
    Gruß Pepi
     
  5. Hobbes_

    Hobbes_ Gast

    Ein Beispiel für einen modifizierten Prompt findet sich auch hier. Danke Skeeve!
     

Diese Seite empfehlen