Re: XTerm verschluckt die Env.-Variable TMPDIR
Helmut Waitzmann [EMAIL PROTECTED] writes:
»execargs«
ist ein Programm, das mit seinen Parametern argv[1] argv[2] ... die
Funktion execvp(argv[1], { argv[2], argv[3], ...}) aufruft.
$ TMPDIR=/tmp execargs printenv printenv TMPDIR; printf 'Exit Code: %s\n' $?
/tmp
Exit Code: 0
Setze ich jetzt bei »execargs« das Setuid- oder Setgid-Flag auf eine
Benutzer- oder Gruppenkennung, die sich von meiner unterscheidet, erhalte
ich folgende Ausgabe:
$ TMPDIR=/tmp execargs printenv printenv TMPDIR; printf 'Exit Code: %s\n' $?
Exit Code: 1
Das scheint also eine Eigenschaft der Laufzeitumgebung zu sein. »xterm«
tut es also nicht explizit.
Das selbe in grün mit screen(1). Es scheinen also wohl alle suid- und
sgid-Programme betroffen zu sein.
Die Vermutung liegt nahe, dass die Ursache im C-library oder im
Startup-Code liegt.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheit vorm bösen Internet
Matthias Houdek [EMAIL PROTECTED] writes: Montag, 3. April 2006 01:23 - Christoph Grzeschik wrote: Schau dir ggf. auch mal chroot an, damit kannst du Programme in einer eigenen, abgesicherten Systemumgebung laufen lassen. Falls Christoph Grzeschik kein profundes Wissen um »chroot« hat, solltest Du Deinen Vorschlag lieber so formulieren: Den Rat »Schau dir ggf. auch mal chroot an« solltest Du lieber nicht leichtfertig befolgen, denn sofern Du es nicht vollständig verstanden hast, wirst du damit Programme in einer eigenen, ungesicherten Systemumgebung laufen lassen, und aus dieser Systemumgebung werden sie ausbrechen. Vor den Prozessen, die in einer »chroot«-Umgebung laufen, ist der Rest des Rechners mitnichten geschützt: »chroot« ist keine Sandkastenumgebung, in der man nichts kaputt machen kann. Ein Beispiel sei hier nur genannt: der Systemaufruf »kill«. Umgekehrt bedeutet eine chroot-Umgebung: Du musst diese Umgebung wie einen weiteren Rechner -- wenn auch sehr spartanisch -- vollständig konfigurieren: Das bedeutet doppelten Aufwand. Stell Dir nur mal vor, ein Prozess in der chroot-Umgebung erhält wegen eines Sicherheitslochs aufgrund einer Fehlkonfiguration Zugriff auf den Festplattencontroller. Dann ist die ganze chroot-Umgebung für die Katz. Nein, »chroot« ist nur was für Leute, die sich damit aus dem FF auskennen. Nicht umsonst ist der Systemaufruf »chroot« Prozessen mit der maßgeblichen Benutzerkennung »root« vorbehalten. Hinweis zum Weiterdenken, warum das so ist: »chroot« kann aus der Datei in meinem HOME-Verzeichnis »/home/helmut/rootjail/etc/passwd«, die natürlich mir gehört und von mir manipuliert werden kann, ruckzuck eine Datei mit dem Namen »/etc/passwd« werden lassen. Jetzt fehlt nur noch das ganz normale »su«-, »sudo«- oder »login«-Programm dazu. Wenn ich das auch noch geschafft habe, dann gute Nacht... -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XTerm verschluckt die Env.-Variable TMPDIR
:
break;
}
}
}
else
{
fprintf(stderr,
%s: At least one argument (command) is
required.\n
Syntax:\n
%s command [argv0 [argv1 [ ... [argvn\n,
invocation_name, invocation_name
);
}
return 125;
} /* main() */
ist ein Programm, das mit seinen Parametern argv[1] argv[2] ... die
Funktion execvp(argv[1], { argv[2], argv[3], ...}) aufruft.
$ TMPDIR=/tmp execargs printenv printenv TMPDIR; printf 'Exit Code: %s\n' $?
/tmp
Exit Code: 0
Setze ich jetzt bei »execargs« das Setuid- oder Setgid-Flag auf eine
Benutzer- oder Gruppenkennung, die sich von meiner unterscheidet, erhalte
ich folgende Ausgabe:
$ TMPDIR=/tmp execargs printenv printenv TMPDIR; printf 'Exit Code: %s\n' $?
Exit Code: 1
Das scheint also eine Eigenschaft der Laufzeitumgebung zu sein. »xterm«
tut es also nicht explizit.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so:| my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: in welchem Paket ist $programm
Andreas Pakulat [EMAIL PROTECTED] writes: Vorher natuerlich ein apt-file update, falls deine Contents-Dateien nicht up-to-date sind. PS: [EMAIL PROTECTED]:~/projects/pyfilmdbsimpleuiapt-file search apt-file apt-file: etc/apt/apt-file.conf apt-file: etc/bash_completion.d/apt-file apt-file: usr/bin/apt-file apt-file: usr/share/doc/apt-file/README apt-file: usr/share/doc/apt-file/TODO apt-file: usr/share/doc/apt-file/changelog.Debian.gz apt-file: usr/share/doc/apt-file/changelog.gz apt-file: usr/share/doc/apt-file/copyright apt-file: usr/share/man/man1/apt-file.1.gz Das tut bei mir nicht. Vielleicht kannst Du mir helfen? Ich habe Sarge vom offiziellen Satz von CDs installiert. /etc/apt/sources.list enthält auch ganz richtig die Liste der Installations-CDs: deb cdrom:[Debian GNU/Linux 3.1 r1 _Sarge_ - Official i386 Binary-14 (20051220)]/ unstable main deb cdrom:[Debian GNU/Linux 3.1 r1 _Sarge_ - Official i386 Binary-13 (20051220)]/ unstable contrib main ... u.s.f. bis deb cdrom:[Debian GNU/Linux 3.1 r1 _Sarge_ - Official i386 Binary-2 (20051220)]/ unstable main deb cdrom:[Debian GNU/Linux 3.1 r1 _Sarge_ - Official i386 Binary-1 (20051220)]/ unstable contrib main # apt-file update verlangt dann auch alle diese 14 CDs nacheinander, spuckt aber die Fehlermeldungen # apt-file --cdrom-mount /media/cdrom1 update Put CDROM labeled [Debian_GNU/Linux_3.1_r1__Sarge__-_Official_i386_Binary-14_(20051220)]/ in the cdrom device cp: cannot stat `/media/cdrom1/dists/unstable/Contents-i386.gz': No such file or directory Put CDROM labeled [Debian_GNU/Linux_3.1_r1__Sarge__-_Official_i386_Binary-13_(20051220)]/ in the cdrom device cp: cannot stat `/media/cdrom1/dists/unstable/Contents-i386.gz': No such file or directory ... u.s.f. bis Put CDROM labeled [Debian_GNU/Linux_3.1_r1__Sarge__-_Official_i386_Binary-2_(20051220)]/ in the cdrom device cp: cannot stat `/media/cdrom1/dists/unstable/Contents-i386.gz': No such file or directory Put CDROM labeled [Debian_GNU/Linux_3.1_r1__Sarge__-_Official_i386_Binary-1_(20051220)]/ in the cdrom device cp: cannot stat `/media/cdrom1/dists/unstable/Contents-i386.gz': No such file or directory cp: cannot stat `//var/cache/apt-build/repository/dists/apt-build/Contents-i386.gz': No such file or directory und beendet sich schließlich mit exit-code 0. Danach findet $ apt-file search apt-file nichts. Was mache ich falsch? Zeigen die Fehlermeldungen trotz exit-code 0 das Scheitern von apt-file an? Wer hat Hinweise, wo ich nach dem Fehler suchen und wie ihn beheben könnte? Sind die Debian-CDs unvollständig? Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Verfall von Passwoertern
Helmut Waitzmann [EMAIL PROTECTED] writes: Joerg Sommer [EMAIL PROTECTED] writes: Helmut Waitzmann [EMAIL PROTECTED] wrote: [Der Benutzer wird beim Login aufgefordert, sein Passwort zu ndern, weil es zu alt geworden ist.] Was passiert bei einem grafischen Login? Ich habe schon befrchtet, dass Du diese Frage stellen wrdest... Ich bin mir nicht mehr sicher, meine aber einmal bei HP-UX schon mal gesehen zu haben, dass man dann ein xterm prsentiert bekommt, in dem das Programm passwd luft. Keine Ahnung, was bei Debian passiert. Knntest du auch mal ein grafisches Login wie kdm oder xdm probieren? Ich sehe bei diesen Programmen schlecht eine Mglichkeit eine zustzliche Abfrage nach einem neuen Passwort zu machen. Ich habe es bei Debian Sarge mal ausprobiert: Es wird nach einem neuen Passwort gefragt. Ich habe ein Account versuchskaninchen eingerichtet und mit ihm folgendes angestellt: $ date --iso-8601=seconds 2005-05-31T19:51:49+0200 $ sudo -u root chage -m 4 -M 6 -I 2 -W 4 -d '2005-05-24' versuchskaninchen $ sudo -u root sudo -u versuchskaninchen chage -l versuchskaninchen Minimum:4 Maximum:6 Warning:4 Inactive: 2 Last Change:Mai 24, 2005 Password Expires: Mai 30, 2005 Password Inactive: Jun 01, 2005 Account Expires:Never Versuchskaninchens Passwort ist also (anscheinend) am 24. Mai zuletzt gendert worden und daher seit 30. Mai (also 6 Tage spter) abgelaufen. Gesperrt ist es noch nicht: Das wird es erst 8 Tage nach dem 24. Mai, also am 1. Juni. Wenn jetzt das Versuchskaninchen am gdm zur Anmeldung die Benutzerkennung und das bestehende, veraltete Passwort eingetippt hat, wird eine Meldung ausgegeben, dass das Passwort abgelaufen sei und jetzt gendert werden msse. Dann wird das Versuchskaninchen nochmals nach dem bestehenden Passwort gefragt und -- wenn es richtig eingetippt worden ist -- anschlieend zwei mal nach einem neuen. Hat es das eingetippt, fhrt ganz normal eine grafische Sitzung hoch. Entsprechend verhlt es sich beim textorientierten Zugang mit dem Programm login: Nach erfolgter nderung des Passwortes wird ganz normal eingeloggt. Setze ich Versuchskaninchens Passwort-Alter so, dass nur gewarnt wird: $ sudo -u root chage -m 4 -M 6 -I 2 -W 4 -d '2005-05-26' versuchskaninchen $ sudo -u root sudo -u versuchskaninchen chage -l versuchskaninchen Minimum: 4 Maximum: 6 Warning: 4 Inactive:2 Last Change: Mai 26, 2005 Password Expires:Jun 01, 2005 Password Inactive: Jun 03, 2005 Account Expires: Never erhlt es sowohl beim textorientierten wie auch beim grafischen Zugang eine Warnmeldung, kann sich aber wie gewohnt anmelden. Setze ich Versuchskaninchens Passwort-Alter so, dass es zwar Zeit zum ndern des Passworts ist, das Passwort aber noch nicht alt genug ist: $ sudo -u root chage -m 8 -M 6 -I 2 -W 4 -d '2005-05-24' versuchskaninchen $ sudo -u root sudo -u versuchskaninchen chage -l versuchskaninchen Minimum: 8 Maximum: 6 Warning: 4 Inactive:2 Last Change: Mai 24, 2005 Password Expires:Mai 30, 2005 Password Inactive: Jun 01, 2005 Account Expires: Never wird es ebenfalls aufgefordert, ein neues Passwort zu whlen (im Einzelnen wie oben), bevor es dann aber dazu kommt, ein neues einzutippen, bricht passwd ab mit der Meldung, man msse noch lnger warten, bis man das Passwort ndern knne. Das heit also, man kommt nicht mehr ins System rein. Fazit: Ist das Passwort zu alt (Lebenszeit; setze diese Schranke mit chage -M oder passwd -x, wird der Benutzer nicht mehr ins System reingelassen, ohne das Passwort neu zu setzen. Ist dann das Passwort noch nicht zu lange zu alt (Wiederbelebungszeit; setze diese Schranke mit chage -I oder passwd -i), wird der Benutzer aufgefordert, sich mit seinem bisherigen Passwort auszuweisen. Ist das bisherige Passwort inzwischen alt genug (Ende der Reifezeit; setze diese Schranke mit chage -m oder passwd -n), darf er sich ein neues Passwort ausdenken und zweimal eintippen. In allen Fllen gilt: Ist es Zeit zu warnen (Warnzeit; setze diese Schranke mit chage -W oder passwd -w), wird vor dem Ende der Lebenszeit des Passwortes gewarnt; und dabei ist es egal, ob das Passwort schon reif genug fr eine nderung ist oder nicht. Zeitpunkt der letzten nderung des Passworts | v -- Zeit Reifezeit +| Lebenszeit+-|-- Wiederbelebungszeit | +| Warnzeit
Re: Shell Skript Problem beim Kommandoaufruf inkl. (
Jean Fiedler [EMAIL PROTECTED] writes:
if [ `(diff (gzip -dc $LASTBACKUP | tar tvf -) (gzip -dc
$BDIR/CVS_Backup_$DATE.tar.gz | tar tvf -)) | wc -l` != 0 ] ; then
beim ausfhren mekert er aber und sagt
syntax error at line 1: `(' unexpected
Ich denke mal er strt sich an der Klammer.
Wie mu ich das jetzt quoten? mit \ vor jeder klammer hab ichs schon
versucht.
Vermutlich willst Du das Process Substitution des bash nutzen, richtig?
Dann ist an den runden Klammern nichts zu maskieren.
Die Fehlermeldung
syntax error at line 1: `(' unexpected
ist aber recht sprlich. Um da weiter zu kommen, knntest Du
* erstmal alle weiteren Fehler, die durch Variablenexpansion ohne
auftreten knnte, ausschlieen, also:
$ if [ `(diff (gzip -dc $LASTBACKUP | tar tvf -) (gzip -dc \
$BDIR/CVS_Backup_$DATE.tar.gz | tar tvf -)) | wc -l` != 0 ] ; then
(Beachte die eingefgten Anfhrungszeichen.),
* zuvor das Kommando
$ set -x
einfgen, damit das Shell ausspuckt, was es gerade macht,
* dein kompliziertes Kommando zur Fehlersuche zerlegen, etwa
$ diff (gzip -dc $LASTBACKUP | tar tvf -) (gzip -dc \
$BDIR/CVS_Backup_$DATE.tar.gz | tar tvf -) /dev/null
oder gar
$ cat -- (date)
ausprobieren, um zu sehen, ob das Shell das versteht.
* im Manual-Page deines Shells berprfen, ob es die (...)- und
(...)-Geschichten berhaupt kennt.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so:| my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Verfall von Passwoertern
Joerg Sommer [EMAIL PROTECTED] writes: Helmut Waitzmann [EMAIL PROTECTED] wrote: [Der Benutzer wird beim Login aufgefordert, sein Passwort zu ndern, weil es zu alt geworden ist.] Was passiert bei einem grafischen Login? Ich habe schon befrchtet, dass Du diese Frage stellen wrdest... Ich bin mir nicht mehr sicher, meine aber einmal bei HP-UX schon mal gesehen zu haben, dass man dann ein xterm prsentiert bekommt, in dem das Programm passwd luft. Keine Ahnung, was bei Debian passiert. Am besten, Du richtest ein Probieraccount mit sehr kurzen Zeiten ein und probierst es tglich aus. Knntest du auch mal ein grafisches Login wie kdm oder xdm probieren? Ich sehe bei diesen Programmen schlecht eine Mglichkeit eine zustzliche Abfrage nach einem neuen Passwort zu machen. Ich habe mir weder xdm, noch gdm, noch kdm angesehen. Prinzipiell knnte man es jedoch so machen, dass der jeweilige Login-Manager (der Benutzername und Passwort entgegennimmt) prft, ob das Passwort veraltet ist und dann, anstelle die bliche Sitzung hochzufahren, eine spezielle hochfhrt, die dem gerade frisch angemeldeten Benutzer nur ein xterm (oder vergleichbares) mit einem darin laufenden passwd prsentiert. Dadurch wrde der Benutzer nach dem erfolgreichen ndern seines Passwortes automatisch ausgeloggt (sowohl passwd als auch xterm kommen zu Ende) und knnte sich erneut -- jetzt mit neuem Passwort -- anmelden. Aber ausprobiert habe ich es noch nicht. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Verfall von Passwoertern
Simon Brandmair [EMAIL PROTECTED] writes: Hallo! Bei der bersetzung der Manpage von passwd bin ich darber gestolpert, wie der Verfall der Passwrter funktioniert. On Wed, 13 Apr 2005 10:30:14 +0200, Simon Brandmair wrote: Ehrlich gesagt bin ich nicht komplett durchgestiegen, wie der Verfall der Passwrter funktioniert. Aus der englischen Manpage: The -w option is used to set the number of days of warning the user will receive before his/her password will expire. The warning occurs warn days before the expiration, telling the user how many days remain until the password is set to expire. The -i option is used to disable an account after the password has been expired for a number of days. After a user account has had an expired password for inact days, the user may no longer sign on to the account. Ich habe das so verstanden: 1. Nutzer bekommt warn Tage eine Warnung vor dem Verfall des Passworts. 2. Wenn der Nutzer sein Passwort nicht ndert, verfllt es. Er kann sich aber noch einloggen, wird dann aber sofort Ich habe es noch nicht ausprobiert, vermute aber, dass statt aufgefordert, da gezwungen stehen sollte: Beim Einloggen wird, anstatt das in /etc/passwd vermerkte Shell zu starten, das Programm passwd gestartet. Das htte dann die Konsequenz, das der Nutzer sein Account erst wieder (produktiv) verwenden kann, wenn er sein Passwort gendert hat. sein Passwort zu ndern. 3. Nach inact Tagen nach dem Verfall des Passworts wird sein Konto gesperrt. Konto gesperrt bedeutete dann: Der Nutzer wird auch nicht mehr an das Programm passwd rangelassen: Es geht berhaupt nichts mehr. Am besten, Du richtest ein Probieraccount mit sehr kurzen Zeiten ein und probierst es tglich aus. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Wie bringe ich dem xterm utf8 bei?
Eduard Bloch [EMAIL PROTECTED] writes: de_DE.UTF-8 ist dokumentiert und wird so von debconf/locales-postinst gesetzt. Kannst Du mir dazu einen Hinweis geben, wo? Das einfache Zeigen der Zeichenkette de_DE.UTF-8 im dpkg-reconfigure-Dialog kann ich nicht als dokumentiert bezeichnen. Dann eher schon ein extra gestartetes Kommando locale -a: Das Manual-Page locale(1) spricht von write names of available locales. Beim Aufsetzen meines Debian/Linux-Rechners habe ich als Standard-Locale zunchst C ausgewhlt und dann noch weitere Locales installiert: Unter allen, die mir von # dpkg-reconfigure locales angeboten wurden, habe ich u.a. alle de_DE-Locales zur Installation ausgewhlt. Das waren diese hier: de_DE.UTF-8 UTF-8 [EMAIL PROTECTED] UTF-8 de_DE ISO-8859-1 [EMAIL PROTECTED] ISO-8859-15 Trotzdem bietet mir $ locale -a kein de_DE.UTF-8, sondern nur de_DE.utf8 an. Da muss man sich schon auf sehr abstrusen Wegen etwas zusammendichten, um auf was anderes zu kommen, erst recht auf de_DE.utf8. Wenn also $ locale -a auf abstrusen Wegen etwas zusammendichtet, dann lass mal hren, wie ich mein Debian-System auf ordentliche Weise nach den dokumentierten Namen der installierten Locales fragen kann. Ich kann so auch de.unicode probieren und das Nichtgelingen hier lang und breit ausdiskutieren. Auf diese Idee kommt nicht einmal locale -a. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Wie bringe ich dem xterm utf8 bei?
Andreas Pakulat [EMAIL PROTECTED] writes: On 19.Mai 2005 - 07:00:49, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 15.Mai 2005 - 01:20:39, Helmut Waitzmann wrote: Ja wie den nun: In Deinem ersten Beitrag hast Du die Ausgabe von locale -a noch verworfen: Das Xlib warne hier doch genug. ?? Ich habe gesagt, dass locale -a die verfuegbaren Locales anzeigt, bzw. sollte. Frueher stand da auch de_DE.UTF-8 IIRC, jetzt nicht mehr. Gibt es eine Mglichkeit, das zu konfigurieren? D.h. wo lsst sich beeinflussen, welche Locale-Namen locale -a den installierten Locales zuordnet? So, wie es ist, passt locale -a nicht zu Xlib. Nein, ich meinte nur was dort steht, dass ebend bei locale -m die korrekt gross geschriebene Character Map angezeigt wird. Dass auch auf locale -m offensichtlich kein Verlass ist, siehst Du hier: ?? man locale gelesen? locale -m zeigt einfach nur alle verfuegbaren Character Maps, ich hab keine Ahnung ob damit die momentan unterstuetzten oder wirklich alle gemeinst sind. Sowohl bei locale -a als auch bei locale -m ist im Manual-Page locale(1) von available die Rede. locale -a zeigt nur die momentan vom libc untersttzten Locales an (bei mir gerade mal 18 Stck): $ locale -a | \ (while read locale; do LC_ALL=$locale locale; done) spuckt keine Warnungen oder Fehlermeldungen aus. locale -m (man 1 locale: Write names of available charmaps) zeigt also wenigstens die momentan untersttzten Character Maps an. Jedenfalls wird bei $ LC_ALL=POSIX locale charmap ANSI_X3.4-1968 ein momentan untersttztes Character-Map angezeigt, denn das locale POSIX wird immer untersttzt. Und es ist daher auch in der mit locale -m angezeigten Liste enthalten: $ locale -m | grep -e '^ANSI_X3\.4-1968$' ANSI_X3.4-1968 Und dennoch taugt ANSI_X3.4-1968 nicht als Bezeichnung des Character-Maps im Namen des Locales: $ LC_ALL=POSIX.ANSI_X3.4-1968 LANG=POSIX.ANSI_X3.4-1968 locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=POSIX.ANSI_X3.4-1968 LC_CTYPE=POSIX.ANSI_X3.4-1968 LC_NUMERIC=POSIX.ANSI_X3.4-1968 LC_TIME=POSIX.ANSI_X3.4-1968 LC_COLLATE=POSIX.ANSI_X3.4-1968 LC_MONETARY=POSIX.ANSI_X3.4-1968 LC_MESSAGES=POSIX.ANSI_X3.4-1968 LC_PAPER=POSIX.ANSI_X3.4-1968 LC_NAME=POSIX.ANSI_X3.4-1968 LC_ADDRESS=POSIX.ANSI_X3.4-1968 LC_TELEPHONE=POSIX.ANSI_X3.4-1968 LC_MEASUREMENT=POSIX.ANSI_X3.4-1968 LC_IDENTIFICATION=POSIX.ANSI_X3.4-1968 LC_ALL=POSIX.ANSI_X3.4-1968 Und dem xterm bzw. Xlib gefllt es auch nicht: $ LC_ALL=POSIX.ANSI_X3.4-1968 LANG=POSIX.ANSI_X3.4-1968 xterm Warning: locale not supported by C library, locale unchanged Also ist locale -m nicht geeignet, eine fr das Xlib passende Liste von charmap-Bezeichnungen in Locale-Namen bereitzustellen. Da sehe ich: Joel Becker hat im BTS unter Bug#117798 bereits ein Bug-Report verfasst, das zu diesem Problem sehr hnlich ist. Also ist das Problem bereits bekannt. Im Bug#154556 schreibt Florian Weimer Also ist dein Problem jetzt geloest? Leider nein. Wo kann man einstellen, dass die von locale -a ausgegebenen Locale-Namen auch fr das Xlib taugen? Vielleicht ist es ja in x.org gefixt und wird dann im naechsten stable funktionieren... Man soll die Hoffnung nie aufgeben. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Wie bringe ich dem xterm utf8 bei?
Andreas Pakulat [EMAIL PROTECTED] writes: On 15.Mai 2005 - 01:20:39, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 12.Mai 2005 - 18:35:15, Helmut Waitzmann wrote: Wie kommt man an die Liste der installierten locales? Ich habe mich bei locale -a umgesehen. Ist locale -a nicht genau dafr vorgesehen? Jupp... Anscheinend doch nicht: Doch es ist dafuer vorgesehen, es zeigt die im System verfuegbaren locales an. Ja wie den nun: In Deinem ersten Beitrag hast Du die Ausgabe von locale -a noch verworfen: Das Xlib warne hier doch genug. Wenn es das falsch tut, muss man einen Bugreport schreiben. Den schreibe ich aber erst, wenn meine ursprngliche Frage Was kann man tun, damit locale -a zu xlib passt? Ist etwa die Konfiguration unvollstndig? Hieb- und Stichfest mit Es geht nicht, da liegt ein Fehler vor, beantwortet werden kann. Bei mir auch nicht, allerdings zeigt locale -m (die Kodierungen, bzw. Character Maps) kein kleingeschriebenes utf8, sondern ebend UTF-8. Willst Du damit sagen, locale -m sei eine verlssliche Quelle fr Kodierungsangaben, die man an den Namen eines Locales, durch einen . getrennt, anhngen kann, unabhngig davon, ob locale -a dieses zusammengeklebte Locale nennt? Etwa so: Nein, ich meinte nur was dort steht, dass ebend bei locale -m die korrekt gross geschriebene Character Map angezeigt wird. Dass auch auf locale -m offensichtlich kein Verlass ist, siehst Du hier: Bei gewissen in locale -m enthaltenen Zeilen, z.B. ANSI_X3.110-1983 ANSI_X3.4-1968 habe ich allerdings meine Zweifel: Tja, manches duerften ziemlich exotisce CharMaps sein... Das wrde ich von diesen beiden gerade nicht behaupten: Sie sind nmlich auch unter dem Namen ASCII bekannt... Schreib einen Bugreport gegen locales. Oder gegen Xlib? Im Gegensatz zu Xlib kommt libc nmlich mit der Ausgabe des Programms locale zurecht. Da sehe ich: Joel Becker hat im BTS unter Bug#117798 bereits ein Bug-Report verfasst, das zu diesem Problem sehr hnlich ist. Wenn ich es richtig verstanden habe, gibt Ben Collins darin Xlib die Schuld: libc normalisiert en_US.UTF-8 zu en_US.utf8, whrend Xlib das unterlsst. Im Bug#154556 schreibt Florian Weimer: X (or XFree86) comes with its own locale management. Only the locales listed in /usr/lib/X11/locale/locale.alias are supported, and there are only few UTF-8 locales. If you use an unsupported locale, you get a warning, and the Compose key may not work. The X selection probably shows erratic behavior, too. Of course, the X approach with a separate locale database is horribly broken, like most POSIX locale features. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Wie bringe ich dem xterm utf8 bei?
Andreas Pakulat [EMAIL PROTECTED] writes:
On 12.Mai 2005 - 18:35:15, Helmut Waitzmann wrote:
Wie kommt man an die Liste der installierten locales? Ich habe mich bei
locale -a umgesehen. Ist locale -a nicht genau dafr vorgesehen?
Jupp...
Anscheinend doch nicht:
locale -a kennt noch immer keine .UTF-8-Locales (wie schon zuvor
auch):
$ locale -a
C
de_DE
[EMAIL PROTECTED]
de_DE.iso88591
[EMAIL PROTECTED]
de_DE.utf8
[EMAIL PROTECTED]
Bei mir auch nicht, allerdings zeigt locale -m (die Kodierungen, bzw.
Character Maps) kein kleingeschriebenes utf8, sondern ebend UTF-8.
Willst Du damit sagen, locale -m sei eine verlssliche Quelle fr
Kodierungsangaben, die man an den Namen eines Locales, durch einen .
getrennt, anhngen kann, unabhngig davon, ob locale -a dieses
zusammengeklebte Locale nennt? Etwa so:
canonical_locale ()
{
eval `LC_ALL=$1 locale -k LC_CTYPE | \
sed -e '/^charmap=/ ! d'`
locale=`printf '%s\n' $1 | \
sed -e 's/[EMAIL PROTECTED]@]*//' \
-e '/@/ { s/\(@\)/.'$charmap'\/; b; }' \
-e 's/$/.'$charmap'/' `
printf '%s\n' $locale
}
Bei gewissen in locale -m enthaltenen Zeilen, z.B.
ANSI_X3.110-1983
ANSI_X3.4-1968
habe ich allerdings meine Zweifel:
$ LC_ALL=`canonical_locale C` locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=C
LC_CTYPE=C.ANSI_X3.4-1968
LC_NUMERIC=C.ANSI_X3.4-1968
LC_TIME=C.ANSI_X3.4-1968
LC_COLLATE=C.ANSI_X3.4-1968
LC_MONETARY=C.ANSI_X3.4-1968
LC_MESSAGES=C.ANSI_X3.4-1968
LC_PAPER=C.ANSI_X3.4-1968
LC_NAME=C.ANSI_X3.4-1968
LC_ADDRESS=C.ANSI_X3.4-1968
LC_TELEPHONE=C.ANSI_X3.4-1968
LC_MEASUREMENT=C.ANSI_X3.4-1968
LC_IDENTIFICATION=C.ANSI_X3.4-1968
LC_ALL=C.ANSI_X3.4-1968
Also lst locale -m das Problem auch nicht.
Was tun?
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so:| my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Wie bringe ich dem xterm utf8 bei?
Andreas Pakulat [EMAIL PROTECTED] writes:
On 08.Mai 2005 - 00:59:30, Helmut Waitzmann wrote:
Wenn ich ein xterm in einer utf8-locale-Umgebung starte, erhalte ich von
ihm die Fehlermeldung:
$ (locale -a locale \
exec xterm -hold -geometry -0+0 -e \
sh -c 'locale exec ${1+$@}' sh cat -- utf8.txt)
de_DE.utf8
[EMAIL PROTECTED]
en_GB.utf8
en_US.utf8
LANG=de_DE.utf8
LC_CTYPE=de_DE.utf8
LC_NUMERIC=C
LC_TIME=de_DE.utf8
LC_COLLATE=de_DE.utf8
LC_MONETARY=de_DE.utf8
LC_MESSAGES=C
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8
LC_ALL=
Warning: locale not supported by Xlib, locale set to C
Diese Warnung sollte eigentlich Warnung genug sein.
Beachte: Hier warnt das Xlib im xterm. locale warnt nicht. Es
scheint also mit dem Locale zufrieden zu sein. Im Gegensatz dazu warnt
locale bei Locales, die es nicht kennt, durchaus:
Ein Beispiel fr ein dem Programm locale unbekanntes Codeset:
$ LC_CTYPE=de_DE.ISO-8859-15 locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=C
LC_CTYPE=de_DE.ISO-8859-15
LC_NUMERIC=C
LC_TIME=de_DE
LC_COLLATE=de_DE
LC_MONETARY=de_DE
LC_MESSAGES=C
LC_PAPER=de_DE
LC_NAME=de_DE
LC_ADDRESS=de_DE
LC_TELEPHONE=de_DE
LC_MEASUREMENT=de_DE
LC_IDENTIFICATION=de_DE
LC_ALL=
Ein Beispiel fr ein unbekanntes Language und Territory:
$ LC_CTYPE=fr_FR locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=C
LC_CTYPE=fr_FR
LC_NUMERIC=C
LC_TIME=de_DE
LC_COLLATE=de_DE
LC_MONETARY=de_DE
LC_MESSAGES=C
LC_PAPER=de_DE
LC_NAME=de_DE
LC_ADDRESS=de_DE
LC_TELEPHONE=de_DE
LC_MEASUREMENT=de_DE
LC_IDENTIFICATION=de_DE
LC_ALL=
Das sieht also nach einem Konfigurationsproblem mit dem Xlib aus.
2 Dinge:
1. dpkg-reconfigure locales
Das hatte ich zuvor schon gemacht. Aber fr den Fall, dass es etwas
ntzt:
# dpkg-reconfigure locales
Ich habe alle locales ausgewhlt, deren Name mit de_DE, en_US oder en_GB
beginnt, das waren diese hier:
de_DE.UTF-8 UTF-8
[EMAIL PROTECTED] UTF-8
de_DE ISO-8859-1
[EMAIL PROTECTED] ISO-8859-15
en_GB.UTF-8 UTF-8
en_GB ISO-8859-1
en_GB.ISO-8859-15 ISO-8859-15
en_US.UTF-8 UTF-8
en_US ISO-8859-1
en_US.ISO-8859-15 ISO-8859-15
Das Locale fr_FR, das auch zur Wahl steht, habe ich nicht ausgewhlt.
Jetzt ein xterm (wie im OP) gestartet: Der Fehler tritt noch immer auf.
An einem fehlenden dpkg-reconfigure locales liegt es also nicht.
2. de_DE.UTF-8
Die Kodierung wird gross geschrieben und nicht klein.
Du hast recht, s.u.
Wie kommt man an die Liste der installierten locales? Ich habe mich bei
locale -a umgesehen. Ist locale -a nicht genau dafr vorgesehen?
locale -a kennt noch immer keine .UTF-8-Locales (wie schon zuvor
auch):
$ locale -a
C
de_DE
[EMAIL PROTECTED]
de_DE.iso88591
[EMAIL PROTECTED]
de_DE.utf8
[EMAIL PROTECTED]
deutsch
en_GB
en_GB.iso88591
en_GB.iso885915
en_GB.utf8
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8
german
POSIX
Das Manual-Page setlocale(3) sieht ebenfalls locale -a als Quelle
der Liste aller untersttzten locales an. Allerdings fhrt es als
Beispiel fr ein codeset UTF-8 an:
A locale name is typically of the form
[EMAIL PROTECTED], where language is an
ISO 639 language code, territory is an ISO 3166 country code, and
codeset is a character set or encoding identifier like ISO-8859-1
or UTF-8. For a list of all supported locales, try locale -a,
cf. locale(1).
Das Manual-Page locale(1) bekrftigt die Auskunft ber installierte
Locales:
-a, --all-locales
Write names of available locales.
Es findet sich dort zwar auch noch:
FILES
/usr/share/i18n/SUPPORTED
List of supported values (and their associated
encoding) for the locale name. This representation is
recommended over --all-locales one, due being the
system wide supported values.
/usr/share/i18n/SUPPORTED ist aber nicht sehr vertrauenserweckend, da
darin alle installierbaren (z.B. auch fr_FR), nicht nur die tatschlich
installierten locales enthalten sind, jedoch keine mit .utf8, nur mit
.UTF-8.
Aber du hast dennoch recht:
$ xterm -hold -geometry -0+0 -e \
sh -c 'locale exec ${1+$@}' sh cat -- utf8.txt
(wie im OP) zeigt jetzt keine Fehlermeldungen, aber das gewnschte Ergebnis:
LANG=de_DE.UTF-8
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC=C
LC_TIME=de_DE.UTF-8
LC_COLLATE=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=C
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
Re: Wie bringe ich dem xterm utf8 bei?
Michelle Konzack [EMAIL PROTECTED] writes:
Am 2005-05-08 00:59:30, schrieb Helmut Waitzmann:
Wenn ich ein xterm in einer utf8-locale-Umgebung starte, erhalte ich von
ihm die Fehlermeldung:
$ (locale -a locale \
exec xterm -hold -geometry -0+0 -e \
sh -c 'locale exec ${1+$@}' sh cat -- utf8.txt)
Die Fehlermeldung (die Du nicht zitiert hast):
Warning: locale not supported by Xlib, locale set to C
Was muss ich noch konfigurieren, damit das xterm mit utf8 zurechtkommt?
__( '/home/michelle.konzack/.Xresources/UXTerm' )_
/
| ! $XFree86: xc/programs/xterm/UXTerm.ad,v 1.1 2000/08/26 04:33:53 dawes Exp $
|
| ! Use
| !xterm -class UXTerm
| ! to set resources for UTF-8 mode with corresponding fonts.
|
| #include XTerm-color
|
| *fontMenu.Label: Unicode Fonts
| *VT100*utf8: 1
| *VT100*font2:-misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
|
| *VT100*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
| *VT100*font3:
-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
| *VT100*font4:
-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
| *VT100*font5:
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
| *VT100*font6:
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
\__
Eine Datei $HOME/.Xresources/UXTerm gibt es auf meinem System nicht.
Leider schreibst Du nichts darber, was fr eine Funktion sie bei Dir hat.
Daher muss ich raten: Du verwendest sie als Application-Defaults-Datei.
Unter dieser Annahme habe ich alle Application-Defaults und X-Resources,
die xterm betreffen (nicht nur die von Dir genannten),
in eine Datei geschoben und in dieser Datei, wo immer iso-8859-
auftritt, eine Ersetzung in iso-10646-1 vorgenommen:
$ { appres UXTerm xterm
appres UXTerm uxterm
appres UXTerm
} | sed -e 's/8859-[0-9*]\?/10646-1/g' | xterm-resources.txt
Diese Datei habe ich dann dem xterm als $XENVIRONMENT-Datei bekannt
gemacht und es dann so, wie Du empfiehlst, gestartet:
$ XENVIRONMENT=$PWD/xterm-resources.txt \
export XENVIRONMENT \
xterm -class UXTerm -hold -geometry -0+0 -e \
sh -c 'locale cat -- utf8.txt' sh
Beachte: Laut Manual Page X(7) haben die im $XENVIRONMENT angegebenen
Application-Resources hchste Prioritt.
Dass ich Dir mit den Application-Resources kein X fr ein U vormache,
zeigt folgendes Kommando:
$ egrep -i -e 'vt100[.*](utf8|font)|fontmenu[.*]label' \
$XENVIRONMENT | \
sort | uniq
*fontMenu.Label: Unicode Fonts
*VT100*font1:nil2
*VT100.font2:-*-fixed-medium-r-normal-*-*-50-98-108-c-*-iso10646-1
*VT100*font2:-misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
*VT100.font3:-*-fixed-medium-r-normal-*-*-70-98-108-c-*-iso10646-1
*VT100*font3:
-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
*VT100.font4:-*-fixed-medium-r-normal-*-*-90-98-108-c-*-iso10646-1
*VT100*font4:
-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
*VT100.font5:-*-fixed-medium-r-normal-*-*-100-98-108-c-*-iso10646-1
*VT100*font5:
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
*VT100.font6:-*-fixed-medium-r-normal-*-*-120-98-108-c-*-iso10646-1
*VT100*font6:
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
*VT100.font: -*-fixed-medium-r-normal-*-*-90-98-108-c-*-iso10646-1
*VT100*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
*VT100*utf8: 1
*VT100.utf8Fonts.font2:
-misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
*VT100.utf8Fonts.font3:
-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
*VT100.utf8Fonts.font4:
-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
*VT100.utf8Fonts.font5:
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
*VT100.utf8Fonts.font6:
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
*VT100.utf8Fonts.font:
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
Wie Du siehst, sind alle von Dir angefhrten Application-Resources auf
iso10646-1 eingestellt.
Das Ende vom Lied: Die Ausgabe des Xterms und die Fehlermeldungen sind
trotz Deiner vorgeschlagenen nderungen an den Font-X-Resources und dem
Application-Class die gleichen geblieben wie zuvor.
Dass
xterm -class UXTerm
bei Dir tut, muss an etwas anderem liegen, nicht an dem von Dir
Angefhrten.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so:| my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user
Wie bringe ich dem xterm utf8 bei?
-normal-*-*-70-98-108-*-*-iso8859-* Was muss ich noch konfigurieren, damit das xterm mit utf8 zurechtkommt? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes:
On 12.Nov 2004 - 03:09:15, Helmut Waitzmann wrote:
Das wäre dann ein Manko an Debian Sarge: ein nicht-interaktives
Nicht-Login-Shell und beim Start von KDE vermutlich auch kein
$HOME/.xsession. Folge: Ich kann nichts konfigurieren...
Dann legt man eine $HOME/.xsession an,
Da bringst Du mich auf eine Idee, s.u.
Login-$SHELL immer, $HOME/.xsession nur bei grafischem
Default System Session.
?? Wie funktionniert das denn mit KDE und Gnome Programmen? In
Sid/Sarge muss man wenn man KDE benutzt den gnome-settings-daemon
starten, sonst sehen saemtliche Gnome-Programme ziemlich mistig aus.
Keine Ahnung. Ich nutze KDE nicht.
Das kann ich wohl bei Fedora dann nicht mehr oder, da ja .xsession
nicht ausgewertet wird. Das ist IMHO ein Fehler bei Fedora,
Dreh den Spieß um: Leg einfach eine $HOME/.xsession an, wähl am login
chooser Default System Session und starte in Deiner $HOME/.xsession
alles weitere (z.B. KDE und gnome-settings-daemon) selbst.
Und um automatisches Starten eines Login-Shells zu erzwingen, falls zuvor
noch keines gelaufen ist, könnte man es so machen:
In der Startup-Datei des Login-$SHELLs die Umgebungsvariable
MY_HAVE_LOGINSHELL setzen und in $HOME/.xsession schreiben:
#!/bin/sh
if test -z ${MY_HAVE_LOGINSHELL+defined}
then
# Es ist noch kein Login-Shell gelaufen, starte eines und lasse es
# $HOME/.xsession starten:
#
# Voraussetzung: bash wird im PATH gefunden (muss nicht in /bin
# sein). bash ist hier noetig wegen exec -l.
exec bash -c 'exec -l ${1+$@}' bash $SHELL -c $HOME/.xsession
fi
# Hier folgt der Rest von $HOME/.xsession
Damit startet sich $HOME/.xsession notfalls rekursiv über ein
Login-$SHELL, und man kriegt eine ziemlich distributionsunabhängige
Konfiguration hin.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so:| my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 08.Nov 2004 - 23:30:26, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: [Im folgenden Zitat bezog ich mich darauf, dass Du die Kommandos, die beim Sitzungsstart nur einmal ausgeführt werden sollen, in $HOME/.xsession und in $HOME/.profile schreiben kannst, weil sie so sowohl beim X11-Zugang als auch beim textorientierten Zugang genau einmal ausgeführt werden.] Das stimmt in diesem Fall natürlich. Was die Sache ärgerlich macht, ist, dass das z.B. für die Distribution Fedora Core release 1 bereits nicht mehr stimmt: Dort finden sich in '/etc/X11/gdm/Sessions' die Shellscripte 'GNOME' und 'KDE', die nichts tun, als ein exec /etc/X11/xdm/Xsession gnome bzw. exec /etc/X11/xdm/Xsession kde [... zu starten.] Denn der Witz ist, wie ich mit den Ausschnitten aus Fedoras /etc/X11/xdm/Xsession gezeigt habe, dass bei Fedora Core release 1 *auch beim Zugang über X11* eine der Dateien $HOME/.bash_profile, $HOME/.profile oder $HOME/.login (je nachdem, welches $SHELL man verwendet) abgearbeitet wird, einfach, weil $SHELL als nicht-interaktives Login-Shell gestartet wird. Damit hat man verloren, wenn man seine Account-Initialisierungskommandos sowohl in einer dieser Login-Shell-Startup-Dateien (für den Text-orientierten Zugang), als auch in $HOME/.xsession eingetragen hat: Denn dann werden sie *zweimal* ausgeführt, wenn man beim Login-Chooser das Default System Session (d.h. $HOME/.xsession) ausgewählt hat. Aber auch Fedora Core wird jawohl $HOME/.xsession einlesen Ja, wenn man beim Login-Chooser keines der Session-Managers, sondern Default System Session auswählt. Insofern wäre das passende Vorgehen bei Fedora Core release 1, dass der Benutzer seine Initialisierungs-Kommandos *nur* in die Login-Shell-Startup-Dateien, nicht auch noch in $HOME/.xsession, reinschreibt. Dann werden sie, egal ob der grafische oder der Text-Zugang genutzt wird, genau einmal abgearbeitet, und der Nutzer muss seinen Zugang an nur *einer* Stelle konfigurieren. Allerdings ist shell-unabhängiges Quoting ziemlich schwierig. Grade da ist aber wieder etwas was Debian gerne moechte, naemlich ein #!/bin/sh und demzufolge Shellunabhaengigkeit erreichen... Hier bin ich mir nicht sicher, was Du mit Shellunabhängigkeit meinst: Meinst Du Der Benutzer kann sich sein Login-Shell auswählen und konfigurieren, und der grafische Zugang macht mit diesem vom Benutzer gewählten Shell eine ordentliche Initialisierung, egal, welches Shell der Benutzer sich ausgesucht hat. ? Oder meinst Du Der Benutzer soll sich daran gewöhnen, für die Konfiguration seines Accounts im Falle des grafischen Logins nur seine Datei $HOME/.profile zur Konfiguration zu verwenden. X11 hat mit keinem anderen Shell als /bin/sh etwas zu tun, denn es ignoriert die Umgebungsvariable SHELL und nimmt immer /bin/sh, ist also davon, was der Benutzer als Login-Shell gewählt hat, unabhängig, bürdet ihm aber damit auf, (falls er nicht /bin/sh oder bash als Login-Shell gewählt hat), zwei Login-Shells konfigurieren zu müssen. ? Ich ziehe hier Fedoras Vorgehensweise vor: Mein Account konfiguriere ich in der Startup-Datei meines Login-$SHELLs. Dann wird die Konfiguration immer verwendet, egal, ob ein Text-orientierter oder grafischer Zugang beim Login verwendet wird. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 11.Nov 2004 - 20:23:05, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 08.Nov 2004 - 23:30:26, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Denn der Witz ist, wie ich mit den Ausschnitten aus Fedoras /etc/X11/xdm/Xsession gezeigt habe, dass bei Fedora Core release 1 *auch beim Zugang über X11* eine der Dateien $HOME/.bash_profile, $HOME/.profile oder $HOME/.login (je nachdem, welches $SHELL man verwendet) abgearbeitet wird, einfach, weil $SHELL als nicht-interaktives Login-Shell gestartet wird. Na das ist ja nicht so wild, dann legt man alles in .profile ab. Es sei denn, man nutzt Debian Sarge. Dann ergeht es einem wie Christine Slotty (Zitat): | Es handelt sich bei der Shell, die ich meine, vermutlich nicht um eine | Login-Shell, denn ich spreche von der unter KDE (die Konsole). Aha. Sie nutzt also KDE als session manager. | Bisher habe ich RedHat benutzt, und da waren zumindest die Änderungen | in der .bash_profile immer auch auf der Konsole vorhanden. Genau. Das sind sie deswegen, weil es vermutlich RedHat wie Fedora richtig macht und ein nicht-interaktives Login-$SHELL startet: exec -l $SHELL -c ... | Mein bisheriger Stand war der, dass man Änderungen in der | .bash_profile in KDE erst aktiviert indem man sich an KDE neu | anmeldet, weil es eben nur eine ursprüngliche Login-Shell gibt, die | ihre Umgebungs-Einstellungen dann aber an die Konsole weitergibt. Genau. Das ist das einzig sinnvolle: Das ganze KDE bekommt meine Umgebungs-Einstellungen von meinem nicht-interaktiven Login-$SHELL vererbt und alles ist in Butter. | Das scheint nun hier in Debian nicht der Fall zu sein, und das wäre | dann das was ich übersehen habe. Das wäre dann ein Manko an Debian Sarge: ein nicht-interaktives Nicht-Login-Shell und beim Start von KDE vermutlich auch kein $HOME/.xsession. Folge: Ich kann nichts konfigurieren... An Christine: Versuche mal, den gdm als Login-Manager zu verwenden und dann dort, wenn Du Deine Sitzung mit KDE betreiben willst, KDE auszuwählen. In meinem Debian Woody passiert da dann folgendes: Es wird das bash-Shell-Script /etc/gdm/Sessions/KDE gestartet, das so beginnt (sieh nach, ob das bei Sarge ebenso ist): #!/bin/bash -login Es ist also ein nicht-interaktives bash-Login-Shell-Script und sollte daher Deine $HOME/.bash_profile oder $HOME/.profile lesen. Prüfe mal nach, ob diese Dateien tatsächlich nicht gelesen werden. Das wäre dann ein Problem von Sarge. Damit hat man verloren, wenn man seine Account-Initialisierungskommandos sowohl in einer dieser Login-Shell-Startup-Dateien (für den Text-orientierten Zugang), als auch in $HOME/.xsession eingetragen hat: Denn dann werden sie *zweimal* ausgeführt, wenn man beim Login-Chooser das Default System Session (d.h. $HOME/.xsession) ausgewählt hat. Du meinst wenn man Default System Session waehlt wird sowohl .xsession ausgewertet als auch .profile? So ist es: zuerst (je nach $SHELL) $HOME/.bash_profile, $HOME/.profile oder $HOME/.login, danach $HOME/.xsession. Naja auch da kann man sich mit einer in .profile zu definierenden Variable behelfen. Das wäre wohl zu tun: In Login-$SHELLs Startup-Datei eine Umgebungsvariable, die anzeigt, dass ein Login-Shell gelaufen ist, setzen und in $HOME/.xsession dann keine Initialisierung mehr vornehmen, wenn diese Variable gesetzt ist. Aber auch Fedora Core wird jawohl $HOME/.xsession einlesen Ja, wenn man beim Login-Chooser keines der Session-Managers, sondern Default System Session auswählt. Insofern wäre das passende Vorgehen bei Fedora Core release 1, dass der Benutzer seine Initialisierungs-Kommandos *nur* in die Login-Shell-Startup-Dateien, nicht auch noch in $HOME/.xsession, reinschreibt. Dann werden sie (gemeint sind die Initialisierungs-Kommandos) , egal ob der grafische oder der Text-Zugang genutzt wird, genau einmal abgearbeitet, und der Nutzer muss seinen Zugang an nur *einer* Stelle konfigurieren. Da bringst du jetzt was durcheinander. Nein, nein, das verhält sich bei Fedora genau so, wie ich in dem Abschnitt, den Du zitierst, geschrieben habe. Und das ist auch gut so: Login-$SHELL immer, $HOME/.xsession nur bei grafischem Default System Session. Denn Text-Zugang wertet niemals .xsession aus, wenn doch machen die da ziemlichen Schweinkram. Wer behauptet denn so etwas? Das wäre in der Tat Unsinn; aber ich kann Dich beruhigen: Es ist nicht der Fall. Damit ich dich richtig verstehe bei jedem grafischen Login ausser Default System Session wird .profile (durch eine login-Shell) ausgewertet aber .xsession nicht. Genau. Und bei dem Default System Session wird .xsession zusaetzlich zu .profile ausgewertet? Dann ist die Loesung doch einfach - nur in .profile definieren. Genau. Und so hatte es auch Christine Slotty (von RedHat her), bis sie bei Debian Sarge auf die Nase gefallen ist. In jedem Falle sind eh Unterschiede von Distri zu Distri
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 30.Oct 2004 - 22:44:23, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 26.Oct 2004 - 02:06:34, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Die Auswahl KDE im Sessions-Men des GDM, /etc/gdm/Sessions/KDE, macht es richtig: Das shell script beginnt mit folgender Zeile: #!/bin/bash -login Das ist ein (nicht-interaktives) Login-bash-Skript, das beim Start zunchst /etc/profile und danach $HOME/.bash_profile oder $HOME/.profile liest. Also /etc/kde3/kdm/Xsession sourced /etc/X11/Xsession und hat #! /bin/sh Also in unstables gdm gibts keine KDE Session und da die eine bash benutzt wuerde ich ja mal behaupten wollen, die hast du selbst geschrieben oder? Bei mir war es in der Debian-Woody-Distribution so drin. Ich habe daran nichts verndert. Beim Login mittels eines Display-Managers haengt der X11-Server am Displaymanager: init kdmXFree86 kdmx-session-managgnome-settings- kwrapper ssh-agent kdm, wiederum wird von init ausgefuehrt, als letztes der Init-Skripte und benutzt wiederum soweit ich das sehe eine nicht-interaktive nicht-login-shell. Wenn da also kdm oder x-session-manag (ksmserver?) keine $HOME/.profile entsprechende Konfigurationsmglichkeit bietet, sieht es in der Tat nicht gut aus. x-session-manager == /etc/alternatives/x-session-manager und das zeigt aufs startkde Skript. Wie gesagt ich kann solche Sachen die nur einmal ausgefuehrt werden sollen mit in meine $HOME/.xsession schreiben, die wird beim Start der Session ausgefuehrt und sonst nicht, aehnlich .profile bei normalen login-Shells. Das stimmt in diesem Fall natrlich. Was die Sache rgerlich macht, ist, dass das z.B. fr die Distribution Fedora Core release 1 bereits nicht mehr stimmt: Dort finden sich in '/etc/X11/gdm/Sessions' die Shellscripte 'GNOME' und 'KDE', die nichts tun, als ein exec /etc/X11/xdm/Xsession gnome bzw. exec /etc/X11/xdm/Xsession kde zu starten. /etc/X11/xdm/Xsession aber ist ein bash-Shellscript, in dem (je nachdem, was fr ein Session man ausgewhlt hat) zum Schluss eines der folgenden Kommandos ausgefhrt wird: exec -l $SHELL -c $SSHAGENT /usr/share/apps/switchdesk/Xclients.$1; exec -l $SHELL -c xterm -geometry 80x24-0-0 exec -l $SHELL -c $SSHAGENT gnome-session exec -l $SHELL -c $SSHAGENT /usr/share/apps/switchdesk/Xclients.kde exec -l $SHELL -c $SSHAGENT /usr/share/apps/switchdesk/Xclients.twm exec -l $SHELL -c $SSHAGENT $1 exec -l $SHELL -c $SSHAGENT $HOME/.xsession exec -l $SHELL -c $SSHAGENT $HOME/.Xclients exec -l $SHELL -c $SSHAGENT /etc/X11/xinit/Xclients exec -l $SHELL -c xsm Das wird jedesmal des Benutzers $SHELL als nicht-interaktives login-shell gestartet (siehe Beschreibung des Parameters -l zum Kommando exec des bash) und ihm ein Kommando bergeben, das dann jeweils das gewnschte Session hochfhrt. Das halte ich fr (beinahe) vorbildlich: Egal, welches shell sich der Benutzer als $SHELL (via /etc/passwd o..) auch ausgesucht und via $HOME/.bash_profile, $HOME/.profile oder $HOME/.login konfiguriert hat: Es wird als nicht-interaktives login-shell gestartet. Damit ist eine ordentliche Konfiguration nach des Benutzers Wnschen sichergestellt. Knnte so etwas Debian nicht auch hinbekommen? Beinahe vorbildlich nenne ich es deshalb, weil beim Zusammensetzen der Kommandozeile (der Parameter zum $SHELL-option '-c') Variablen-Auswertungen ohne Quoting verwendet werden. Soweit aber die Variablen SSHAGENT, HOME und 1 fr das betreffende $SHELL unzerbrechliche Werte enthalten (was vermutlich der Fall sein drfte), ginge das nochmal gut. Das prft aber /etc/X11/Xsession zuvor nicht ab. Allerdings ist shell-unabhngiges Quoting ziemlich schwierig. Am ehesten knnte ich mir da noch folgende Vorgehensweise vorstellen: 1. Schreibe ein ' (ohne die Anfhrungszeichen) hin. 2. Nimm den Variablenwert, setze hinter jedes darin enthaltene Apostroph die Zeichenfolge \'' (ohne die Anfhrungszeichen). 3. Schreibe noch ein ' (ohne die Anfhrungszeichen) hin. So entsteht ein in Apostrophe eingeschlossener Text, dessen in ihm enthaltene Apostrophe ordentlich verpackt sind. Der Knigsweg, statt beispielsweise exec -l $SHELL -c $SSHAGENT $1 lieber exec -l $SHELL -c '$@' -`basename $SHELL` $SSHAGENT $1 hinzuschreiben, scheitert daran, dass erstens der Ausdruck $@ nicht in allen shells fr die positional parameters steht und zweitens manche -- aber nicht alle -- shells in diesem Fall als ersten Parameter nach der Kommandozeile den Namen des shells selbst, mit einem Minuszeichen vorne dran versehen, verlangen: Das bash und das bourne shell verlangen es, das csh und das tcsh verbieten es, das ksh verlangt oder verbietet es je nach Fassung oder OS. Es ist ein Graus. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 26.Oct 2004 - 02:06:34, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Schreib sie in die $HOME/.bashrc, dann werden sie immer eingelesen... Nein. Dann werden sie von allen interaktiven nicht-login-shells eingelesen; nicht-interaktive nicht-login-shells lesen kein ~/.bashrc. Und? Die lesen auch keine .profile oder /etc/profile . Genau. Darum ist es Unsinn, zu sagen Nimm ~/.bashrc, das wird immer eingelesen. Denn das stimmt bei nicht-interaktiven shells nicht. Und weil das erste Shell-Skript, das bei einem grafischen login unter der Kennung des angemeldeten Benutzers gestartet wird, nun einmal von einem nicht-interaktiven shell gelesen wird (interaktive shells gibt es dann erst in Terminal-Emulatoren), kann man ihm nur auf die Weise eine ordentliche Konfiguration verpassen, dass man es zum login-shell macht. Die Auswahl KDE im Sessions-Men des GDM, /etc/gdm/Sessions/KDE, macht es richtig: Das shell script beginnt mit folgender Zeile: #!/bin/bash -login Das ist ein (nicht-interaktives) Login-bash-Skript, das beim Start zunchst /etc/profile und danach $HOME/.bash_profile oder $HOME/.profile liest. Nein, du kannst den ganzen Kram doch in eine ~/.bashrc tun und die noch in der .bash_profile sourcen. Dadurch kommst du bei jeder! Shell in den Genuss deiner Konfiguration. Nein. Nicht-interaktive nicht-login-shells bleiben da auen vor (siehe manual bash(1)). Ja, aber die kannst du sowieso nicht weiter konfigurieren, weder mit *profile, nocht mit *bashrc. Genau. Du hast es ja doch verstanden. Darum halte ich beim startup nicht-interaktive nicht-login-shells eines Fehlerberichtes wert. Nicht-interaktive nicht-login-shells sind im Normalfall Skripte, die saemtliche Umgebungsvariablen selbst setzen muessen... Eigentlich nicht. Eher sind es Skripte, die ihre Umgebungsvariablen bereits fertig in der Umgebung geliefert bekommen. Ich denke immernoch, das *dm keine Loginshell aufmachen, KDE aus der GDM-Auswahl ist ein Login-Shell, die anderen Auswahlmglichkeiten (Debian, Gnome, Xsession) allerdings nicht. da ja saemtliche Prozesse danach direkt an init haengen... Ich sehe zwischen keine Loginshell und smtliche Prozesse direkt an init hngen keinen Zusammenhang. Erklrst Du ihn mir? Klaro: Hab mich da etwas ungluecklich ausgedrueckt... Was ich meinte war: Der X11-Prozess haengt an init. Wenn man mittels startx den Xserver startet sieht das ganze so aus: init | |- bash -- startx -- xinit -- XFree86 .. | |- x-session-manager Und das bash ist ein login shell und baut eine ordentliche Umgebung fr startx usw. auf. Da ist also alles in Ordnung. Beim Login mittels eines Display-Managers haengt der X11-Server am Displaymanager: init kdmXFree86 kdmx-session-managgnome-settings- kwrapper ssh-agent kdm, wiederum wird von init ausgefuehrt, als letztes der Init-Skripte und benutzt wiederum soweit ich das sehe eine nicht-interaktive nicht-login-shell. Wenn da also kdm oder x-session-manag (ksmserver?) keine $HOME/.profile entsprechende Konfigurationsmglichkeit bietet, sieht es in der Tat nicht gut aus. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Den ersten Fall fände ich ein bug report wert, der zweite Fall ist völlig in Ordnung. Wieso? Warum ich den ersten Fall für eines bug reports wert halte: DIE traditionelle Methode, bei der ein Benutzer seinen Zugang konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login shells beim Start einlesen. Der Sicherheit am zuträglichsten ist es, wenn des Benutzers sicherheitsrelevante Eintragungen, wie etwa umask, Umgebungsvariablen, u.a., von jedem Zugang (egal, ob login am Nur-Text-Terminal, kde, gnome, su, slogin, ...) zum System beachtet werden. Schreib sie in die $HOME/.bashrc, dann werden sie immer eingelesen... Nein. Dann werden sie von allen interaktiven nicht-login-shells eingelesen; nicht-interaktive nicht-login-shells lesen kein ~/.bashrc. Aber selbst das ist keine gute Idee, wie das Beispiel mit dem PATH zeigt. Sonst vergisst er garantiert irgendwann, verschiedene Konfigurationsdateien synchron zu halten, mit der Folge, dass irgendein Zugang, etwa xdm, gdm, kdm, su, login, slogin noch ein Sicherheitsloch hat, das der Benutzer bei den übrigen Zugängen bereits gestopft hat. Weil es nun aber den textorientierten Zugang login am Nur-Text-Terminal immer noch gibt und dabei die einzigen Konfigurationsdateien die eines login shells (etwa ~/.profile) sind, muss dort also eine ordentliche Konfiguration vorgenommen werden. Aus den oben genannten Gründen sollten kde, gnome, xdm, su, slogin, ... diese Konfigurationsdatei ebenfalls verwenden, indem sie ein login shell starten. Nein, du kannst den ganzen Kram doch in eine ~/.bashrc tun und die noch in der .bash_profile sourcen. Dadurch kommst du bei jeder! Shell in den Genuss deiner Konfiguration. Nein. Nicht-interaktive nicht-login-shells bleiben da außen vor (siehe manual bash(1)). Klappt hier wunderbar. Meine .bash_profile enthaelt ausser ner Umask eigentlich nur noch das source.. Ich denke immernoch, das *dm keine Loginshell aufmachen, da ja saemtliche Prozesse danach direkt an init haengen... Ich sehe zwischen keine Loginshell und sämtliche Prozesse direkt an init hängen keinen Zusammenhang. Erklärst Du ihn mir? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes:
On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote:
Andreas Pakulat [EMAIL PROTECTED] writes:
Nein, es gibt keine Login-Shell wenn man sich grafisch einloggt.
Verstehe ich Dich richtig, dass beim grafischen login ~/.xsession (oder
äquivalentes) gestartet wird, ohne dass jemals unter der Kennung des
angemeldeten Benutzers ein login shell gelaufen ist?
Oder willst den zitierten Satz nur im Sinne von die Shells in KDE's
konsole sind keine login shells verstanden wissen?
Da fragst du den falschen, so gut kenne ich mich da nicht aus. Aber
die KDE-Prozesse sind alle Kinder von init und nicht (wie bei dem
startx-Verfahren) des X11-Servers (IIRC). Die Shells in KDE (*term,
konsole...) sind alle nicht-login-shells und kriegen offensichtlich
auch keine Einstellungen aus irgendeiner Login-Shell vererbt... Ich
denke mit obigem ist das eventuell erklaerbar (wer wessen Kind ist)...
Den ersten Fall fände ich ein bug report wert, der zweite Fall ist völlig
in Ordnung.
Wieso?
Warum ich den ersten Fall für eines bug reports wert halte:
DIE traditionelle Methode, bei der ein Benutzer seinen Zugang
konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login
shells beim Start einlesen. Der Sicherheit am zuträglichsten ist es,
wenn des Benutzers sicherheitsrelevante Eintragungen, wie etwa umask,
Umgebungsvariablen, u.a., von jedem Zugang (egal, ob login am
Nur-Text-Terminal, kde, gnome, su, slogin, ...) zum System beachtet
werden. Sonst vergisst er garantiert irgendwann, verschiedene
Konfigurationsdateien synchron zu halten, mit der Folge, dass irgendein
Zugang, etwa xdm, gdm, kdm, su, login, slogin noch ein Sicherheitsloch
hat, das der Benutzer bei den übrigen Zugängen bereits gestopft hat.
Weil es nun aber den textorientierten Zugang login am Nur-Text-Terminal
immer noch gibt und dabei die einzigen Konfigurationsdateien die eines login
shells (etwa ~/.profile) sind, muss dort also eine ordentliche
Konfiguration vorgenommen werden. Aus den oben genannten Gründen sollten
kde, gnome, xdm, su, slogin, ... diese Konfigurationsdatei ebenfalls
verwenden, indem sie ein login shell starten.
Warum ich den zweiten Fall für in Ordnung halte:
Ein login shell ist traditionell eines, an dem eine interaktive Sitzung
hängt und mit dem sie steht und fällt. Daher würde ich in die
Konfigurationsdatei eines login shells (etwa ~/.profile, ~/.login,
~/.bash_profile) solche Kommandos stellen, die die Umgebung nicht nur für
dieses shell, sondern für alle daraus gestarteten Prozesse beeinflusst,
beispielsweise umask-, ulimits-, und solche Kommandos, die die
Umgebungsvariablen beeinflussen.
Diese Kommandos sollen aber nur ein einziges Mal innerhalb einer Sitzung
ausgeführt werden, nicht jedes Mal aufs Neue, wenn ich z.B. in kde ein
neues konsole-Fenster öffne. Daher ist der zweite Fall für mich in
Ordnung.
Ein Beispiel soll das verdeutlichen: Angenommen, ich möchte unterhalb
meines HOME-Verzeichnisses ein Verzeichnis anlegen, in das ich
selbstgeschriebene Programme stelle. Diese Programme sollen natürlich
vom shell gefunden werden. Also stelle ich das Verzeichnis in den PATH.
Für das bourne shell nehme ich die Datei ~/.profile und schreibe hinein:
export PATH
PATH=$HOME/bin:${PATH:-/usr/local/bin:/usr/bin:/bin}
Wenn jetzt ein konsole ein login shell starten würde, käme bei jedem
shell, das in einem konsole läuft, an den PATH vorne $HOME/bin/: dran.
Wenn ich also aus einem konsole ein weiteres starte, indem ich darin
konsole
eintippe, wäre $HOME/bin dann schon zweimal im PATH u.s.f., was keine
gute Idee ist.
Daher würde ich innerhalb einer interaktiven Sitzung nur EIN shell als
login shell laufen lassen. Und zwar müsste es das shell sein, von dem
alle meine Prozesse, die ich in der Sitzung starte, die Umgebung
erhalten.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so:| my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: das neue xserver-xfree86 fummelt am PATH herum
Michelle Konzack [EMAIL PROTECTED] writes: Am 2004-10-14 06:45:43, schrieb Helmut Waitzmann: Michelle Konzack [EMAIL PROTECTED] writes: env /home/michelle/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin \ xterm +ls -hold -e printenv PATH Was ist in dem neu gestarteten xterm zu sehen? Ei verflixt. So nützt Dir das natürlich nichts. Da hatte ich Dir Unsinn geschrieben. Vielmehr soll das Kommando so aussehen: env PATH=/home/michelle/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin \ xterm +ls -hold -e printenv PATH Könntest Du das auch noch ausprobieren? Gruß, Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: Nein, es gibt keine Login-Shell wenn man sich grafisch einloggt. Verstehe ich Dich richtig, dass beim grafischen login ~/.xsession (oder äquivalentes) gestartet wird, ohne dass jemals unter der Kennung des angemeldeten Benutzers ein login shell gelaufen ist? Oder willst den zitierten Satz nur im Sinne von die Shells in KDE's konsole sind keine login shells verstanden wissen? Den ersten Fall fände ich ein bug report wert, der zweite Fall ist völlig in Ordnung. Die erhaelst du nur beim einloggen auf der Console. Die Shells in KDE's xterm (konsole genannt ;-) lesen nur /etc/bash.bashrc und ~/.bashrc ein, also hinterlege deine Sachen dort. Dein weiterer Text legt den zweiten Fall nahe. Könntest Du das bitte nochmals deutlich machen? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: Ç und ç unter X
Michelle Konzack [EMAIL PROTECTED] writes: Am 2004-10-12 17:50:27, schrieb Helmut Waitzmann: Michelle Konzack [EMAIL PROTECTED] writes: Für Ç AltGr,C und ç AltGr,c Du meinst AltGr drücken und loslassen, danach C bzw. c drücken und loslassen und Ç bzw. ç erscheint? Neee, Du drückst AltGr, läßt los und drückst c oder C und erhälst ç und Ç Aha. Jetzt ist es klar. (Aus AltGr,c war nicht zu ersehen, wann Du nun die AltGr-Taste loslässt.) Damit ist natürlich alles weitere hinfällig. Kann mir jemand sagen, wie ich das in meine de.map für 'xmodmap' eintragen muß ? keycode 64 = Mode_switch Multi_key Statt der 64 musst Du eventuell ein anderes keycode hinschreiben. Wieso ich ? - bei mir funktionier alles... Meine deutsche Tastatur unterstützt derzeit rund 210 Zeichen. Du willst mich wohl auf den Arm nehmen? In [EMAIL PROTECTED] hast Du es selbst geschrieben. Viel zu kompliziert... das dead_cedilla wurd extra dafür gemacht, das Du schneller schreiben kannst. Wenn man eine 105-Tasten-Tastatur hat. Ich habe teilweise nur eine 101-Tasten-Tastatur zur Verfügung. Da ist dann für eine Mode_switch-Taste (a.k.a. AltGr) kein Platz mehr. Mit Deine eigenartigen Construktion wirste auf dauer nicht froh. Mit 101 Tasten habe ich keine andere Wahl. Und wenn Du Windows $USER mal auf Deiner Kiste Arbeiten lassen willst, geben die sich nen Schuß. Das würden die sowieso, wenn sie auf einer deutschen 105-Tasten-Tastatur mit englischer Tastenbelegung nicht zurechtkommen, weil sie nicht Schreibmaschine schreiben können und daher das Adler-Such-System versagt, oder wenn sie an einer amerikanischen 101-Tasten-Tastatur ohne Umlaut- und Mode_switch-Tasten auskommen müssen... -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
woody: Wo bleibt TMPDIR im xterm?
Auf meinem Rechner läuft woody. Ich habe entdeckt, dass das xterm die Umgebungsvariable TMPDIR, sofern vorhanden, nicht an das Programm, das ich in ihm laufen lasse, vererbt. Kann ich dieses Verhalten abstellen? Soll heißen: Ich möchte, dass xterm an der Umgebungsvariablen TMPDIR nichts verändert. Was kann ich tun? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: woody: Wo bleibt TMPDIR im xterm?
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Helmut Waitzmann [Tue, Oct 12 2004, 09:04:43AM]: Auf meinem Rechner läuft woody. Ich habe entdeckt, dass das xterm die Umgebungsvariable TMPDIR, sofern vorhanden, nicht an das Programm, das ich in ihm laufen lasse, vererbt. Kann ich dieses Verhalten abstellen? Soll heißen: Ich möchte, dass xterm an der Umgebungsvariablen TMPDIR nichts verändert. Da bin ich wohl zu knapp gewesen: Die Umgebungsvariable ist bereits gesetzt, wenn ich xterm starte. Bitte schlage in einem beliebigen Unix-Handbuch nach, wie es sich so mit den Variablen verhält, und in sh/bash-Handbuch, was da zu beachten ist bezüglich export und setzen in .bashrc oder .bash_profile. Ich habe eine Datei $HOME/.profile, in der TMPDIR gesetzt und exportiert wird. Ich habe keine Datei $HOME/.bash_profile. Ich habe außerdem eine Datei $HOME/.bashrc, in der TMPDIR nicht verändert wird. Ein Beispiel: (1) env TMPDIR=$HOME/tmp xterm +ls -e sh -c 'printenv TMPDIR; read line' sh öffnet mir ein xterm, in welchem nichts ausgegeben wird. Im Gegensatz dazu zeigt mir (2) env TMPDIR=$HOME/tmp sh -c 'printenv TMPDIR; read line' sh den Inhalt: /home/helmut/tmp Und da du uns nicht sagst, wie und wo du TMPDIR setzen willst, kann man dir nicht helfen. Ist es jetzt klar? Laut manual page startet das xterm mit dem Parameter +ls ein nicht-interaktives nicht-login-shell: Demnach wird weder $HOME/.bash_profile, noch $HOME/.profile, noch $HOME/.bashrc, noch $ENV eingelesen. Trotzdem unterscheiden sich (1) und (2) in der Umgebungsvariablen TMPDIR. Warum entfernt xterm TMPDIR aus der Umgebung? -- OpenBSD fails miserably in this respect, and makes for an example of how NOT to work with the community on security issues. Their approach is, roughly, we fixed this a while ago but didn't tell anyone, so you're vulnerable and we're not, ha-ha-ha. Ist das auf die Umgebungsvariable TMPDIR zu beziehen (immerhin steht der Text nach einem Signaturtrenner -- )? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: woody: Wo bleibt TMPDIR im xterm?
Andreas Pakulat [EMAIL PROTECTED] writes: On 12.Oct 2004 - 15:19:50, Helmut Waitzmann wrote: Ich habe eine Datei $HOME/.profile, in der TMPDIR gesetzt und exportiert wird. Ich habe keine Datei $HOME/.bash_profile. Ich habe außerdem eine Datei $HOME/.bashrc, in der TMPDIR nicht verändert wird. Ein Beispiel: (1) env TMPDIR=$HOME/tmp xterm +ls -e sh -c 'printenv TMPDIR; read line' sh öffnet mir ein xterm, in welchem nichts ausgegeben wird. Also das klappt auf meinem System wunderbar: [EMAIL PROTECTED]:~env tmpdir=temp xterm +ls -e sh -c 'echo $tmpdir;read line' sh ergibt: temp im xterm DAS tut bei mir auch. Darum geht mir aber nicht: Ich bin nicht an der Umgebungsvariablen tmpdir sondern an der Umgebungsvariablen TMPDIR interessiert, also nicht env tmpdir=temp xterm +ls -e sh -c 'echo $tmpdir;read line' sh sondern env TMPDIR=temp xterm +ls -e sh -c 'printenv TMPDIR;read line' sh . Laut manual page startet das xterm mit dem Parameter +ls ein nicht-interaktives nicht-login-shell: Demnach wird weder $HOME/.bash_profile, noch $HOME/.profile, noch $HOME/.bashrc, noch $ENV eingelesen. Nicht ganz, bei mir steht es ist eine non-login shell. Nichts von nicht-interaktiv. Also wird $HOME/.bashrc eingelesen. Hast Du ein anderes bash(1) manual page? Bei meinem lese ich INVOCATION [...] An interactive shell is one started without non-option arguments and without the -c option whose standard input and output are both con- nected to terminals (as determined by isatty(3)), or one started with the -i option. Ist also eindeutig ein nicht-interaktives shell: Ich habe das option -c angegeben. A login shell is one whose first character of argument zero is a -, or one started with the --login option. Ist also eindeutig ein nicht-login-shell: arg0 (hier: sh) beginnt nicht mit einem - und option --login steht auch nicht da. Und weiter im manual: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read. Welche Startup-Dateien sollten da noch gelesen werden? Und selbst wenn: Ich habe keine Startup-Datei, in der unset TMPDIR steht. Trotzdem unterscheiden sich (1) und (2) in der Umgebungsvariablen TMPDIR. Nicht bei mir. Bist Du wirklich sicher, beim Test von (1) und (2) TMPDIR und nicht etwa tmpdir verwendet zu haben? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: Ç und ç unter X
Michelle Konzack [EMAIL PROTECTED] writes: Für Ç AltGr,C und ç AltGr,c Du meinst AltGr drücken und loslassen, danach C bzw. c drücken und loslassen und Ç bzw. ç erscheint? Dann kann AltGr nur eine dead-key-Taste sein. Aha. Du schreibst es selbst, also sind wir uns einig: Sprich, AltGr, ist wie eine dead-key was auf eine nachfolgende Eingabe wartet. D.h. also, AltGr ist eine Taste, die nach dem Loslassen noch wirkt. Das ist aber nicht das keysym Mode_switch, das traditionell auf die mit AltGr beschriftete Taste gelegt wird: Mode_switch wirkt wie Shift nur, solange man es gedrückt hält. Ich fürchte, beides kannst Du nicht gleichzeitig haben. Du kannst aber (eine Alternative wäre [EMAIL PROTECTED]) auf die mit AltGr beschriftete Taste das keysym Mode_switch und auf die selbe Taste mit Shift zusammen das keysym Multi_key (a.k.a compose key) legen: Kann mir jemand sagen, wie ich das in meine de.map für 'xmodmap' eintragen muß ? keycode 64 = Mode_switch Multi_key Statt der 64 musst Du eventuell ein anderes keycode hinschreiben. Finde es heraus, indem Du $ xev startest und die mit AltGr beschriftete Taste drückst und loslässt. Schau, was xev für ein keycode ausspuckt. Dann kannst Du für ÇShift-AltGr , Shift-c und für çShift-AltGr , c tippen. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: woody: Wo bleibt TMPDIR im xterm?
[xterm frisst die Umgebungsvariable TMPDIR.] Zwei Dinge verwundern mich doch sehr: 1. Das Löschen einer, jedoch nicht aller, Umgebungsvariabler kann doch eigentlich nicht aus Versehen passieren. Es muss also mit Absicht in den Code hineingeschrieben worden sein. 2. Auf einem Fedora Core release 1 (Yarrow) $ uname -msr Linux 2.4.22-1.2199.nptl i686 hat das xterm diese Launen, die Variable TMPDIR zu fressen, nicht. Hat hier Fedora oder Debian ein spezielles xterm? Und wozu soll das gut sein, die Variable TMPDIR zu entfernen? Ich kann da keinen Sinn, jedoch eventuell ein Sicherheitsrisiko, erkennen. Andreas Pakulat [EMAIL PROTECTED] writes: Daher wuerde ich dir raten nen Bugreport gegen xterm zu schreiben. Ja, das dürfte wohl das Beste sein. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
das neue xserver-xfree86 fummelt am PATH herum (was: woody: Wo bleibt TMPDIR im xterm?)
Michelle Konzack [EMAIL PROTECTED] writes: Ich habe in der ~/.bash_profile zum Beispiel export PATH=$HOME/bin:/bin:sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin/ und wenn ich 'startx' eingab, war der PATH immer da. (auch noch auf einer Workststion die von der 3.0r0 installiert wurde.) das gleiche steht in der ~/.xsession drin. All was working fine. Jetzt mach ein 'apt-get upgrade' das Dir den neuen xserver-xfree86 installiert und schon geht nichts mehr. Ein eintippen von 'echo $PATH' gibt lediglich /bin:sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin/ zurück, anstatt /home/michelle/bin:/bin:sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin/ Allerdings wird $MANPATH korrekt übernommen: /home/michelle/man:/usr/share/man:/usr/X11R6/man:/usr/local/man Um dem Übeltäter auf die Schliche zu kommen, würde ich als erstes fahnden: 1. Sind ~/.xsession und ~/.xinitrc noch die alten Dateien oder hat etwa startx daran herumgefummelt? 2. Was macht startx (es dürfte vermutlich ein shell script sein)? Startet es ~/.xsession oder ~/.xinitrc als login-shell script oder als non-login-shell script? Werden weitere Skripte (etwa ~/.clientrc) gestartet? 3. Schreib in ~/.xsession und ~/.xinitrc ein Kommando, das Dir den Inhalt der Variablen HOME per E-Mail schickt. Was kommt für eine Nachricht an? Vermutung: Früher hat ~/.xinitrc auf irgendeine Weise ein nicht-interaktives login shell gestartet (z.B. über #!/bin/bash --login oder exec -l bash -c 'irgendwas ...' -bash ), jetzt tut es das nicht mehr. Ein dringender Verdacht dahin ergäbe sich, wenn der PATH jetzt nicht /bin:sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin/ sondern /bin:/bin:sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin/ wäre (HOME=''). Schaust Du bitte nochmal genau nach? 4. Vielleicht wird auch in startx irgendwo eine Zuweisung auf den PATH gemacht, der alle von Dir getätigten Änderungen wieder überbügelt? Alles nur Vermutungen. Viel Erfolg beim Fahnden. Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: find und tar
Mario Duve [EMAIL PROTECTED] writes: finde in /dir alle Verzeichnisse /xxx und mache dann ein .tar file von jedem xxx Verzeichniss. Das musst Du schon genauer erklären: /xxx liegt garantiert nicht in /dir: Beide liegen in / und daher nebeneinander. Ich vermute, Du meinst etwas anderes. Was genau? müsste ja dann ungefähr so aussehen: find /dir -type d -name xxx -exec tar ??? wie nun weiter ? Aha. Das sieht schon besser aus. find findet so also z.B. die Verzeichnisse /dir/ein/Unterverzeichnis/Namens/xxx und /dir/ein/Unterverzeichnis/Namens/xxx/xxx (vorausgesetzt, es gibt sie). Doch da gibt es weitere Fragen: Soll sowohl von /dir/ein/Unterverzeichnis/Namens/xxx als auch von /dir/ein/Unterverzeichnis/Namens/xxx/xxx ein tape archive erzeugt werden? Wenn ja, bedeutet das, dass der Inhalt von /dir/ein/Unterverzeichnis/Namens/xxx/xxx zweimal -- wenn man es ganz dumm anstellt, sogar dreimal -- archiviert wird. Ist das gewünscht? Oder soll die Rekursionstiefe des Archivs jeweils auf ein Verzeichnis beschränkt werden? Wie sollen die Archive jeweils heißen und in welchem Verzeichnis sollen sie stehen? Von der Beantwortung dieser Fragen hängt alles weitere ab. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: Debian Sarge erkennt keine Audio-CDs
Thorsten Haude [EMAIL PROTECTED] writes: [EMAIL PROTECTED] % login No utmp entry. You must exec login from the lowest level sh login weigert sich, wenn sein controlling terminal keinen utmp-Eintrag hat, oder wenn es kein Sitzungsführer ist. Umgekehrt müssen also folgende Bedingungen erfüllt sein: (1.) logins controlling terminal muss in /var/run/utmp verzeichnet sein. (2.) logins session id (siehe manual page getsid(2)) muss gleich seinem process id sein. (Dann ist login Sitzungsführer.) Auf die erste Bedingung weist der erste Satz der Fehlermeldung hin. Auf die zweite Bedingung weist der zweite Satz der Fehlermeldung hin. Um die erste Bedingung zu erfüllen, müsstest Du login z.B. an der Console, über rlogin/slogin oder in einem utmp-xterm starten. Ein utmp-xterm erhältst Du, indem Du beim Start des xterms den Parameter +ut angibst, siehe (manual page xterm(1)). Um die zweite Bedingung zu erfüllen, kannst Du ein shell, das selbst Sitzungsführer ist, durch einen login-Prozess ersetzen, indem Du in diesem shell das Kommando exec login startest. Das meint der zweite Satz der Fehlermeldung. In der Summe müsste also xterm +ut -e login tun. Ansonsten wäre auch su statt login eine Möglichkeit: su stellt weder die erste noch die zweite Anforderung. (Allerdings ist su auf meinem woody-debian % uname -msr Linux 2.4.18-bf2.4 i686 eine Katastrophe und nicht wirklich brauchbar, wenn es um das Starten eines nicht-interaktiven shells geht.) -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: Compose-Taste
, dann mit dem rechten Ringfinger ein o drücken, dann alle Tasten loslassen: Super_L-Shift(_L)-o oder Super_R mit dem rechten Ringfinger gedrückt halten, dazu die rechte Control-Taste mit dem rechten Kleinen Finger gedrückt halten, dann mit dem linken Kleinen Finger ein a drücken, dann alle Tasten loslassen: Super_R-Control-a -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: Compose-Taste
Dirk Salva [EMAIL PROTECTED] writes: Das liest sich alles sehr interessant, aber kann mir bitte jemand erklaeren, wofuer ich als Otto-Normaluser eine Compose-Taste gebrauchen kann? Ich habe auf meinen Rechner de-latin1-nodeadkeys eingerichtet, und damit bekomme ich eigentlich alle die Zeichen, die ich im taeglichen Leben so brauche. Zumindest faellt mir gerade nix auf, was ich wirklich vermisse, ausser vielleicht das Zeichen fuer 1/2, was ich immerhin schon 1-2x haette nutzen koennen in den letzten - na sagen wir mal zehn Jahren. Ich nutze ebenfalls nodeadkeys. Mit der Compose-Taste kann ich dann z.B. die Zeichen é Multi_key ' e æ Multi_key a e © Multi_key c o ® Multi_key Shift-R Shift-O Ä Multi_key Shift-A § Multi_key s o ¦ Multi_key | | ± Multi_key + - ½ Multi_key 1 2 ¼ Multi_key 1 4 ¾ Multi_key 3 4 ß Multi_key s s ÷ Multi_key - : ø Multi_key / o å Multi_key a o ç Multi_key , c ¿ Multi_key ? ? ¡ Multi_key ! ! eintippen. Und das klappt sogar mit einer 101-Tasten-Tastatur, die noch keine AltGr-, Windows- und Menu-Tasten hat. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
