Nein, ganz so einfach ist es nicht. Denn: a) die shell ist klar eine login shell b) ich habe die --noprofile option NICHT angegeben c) ~/.bash_profile ist definitiv da und wird aber trotzdem bei ssh logins NICHT gesourced (~/.bashrc ist auch da und wird explizit von der ~/.bash_profile aus gesourced) d) Wie gesagt, gibt es einen Unterschied zwischen d1) logins mittels "su - <user_name>" und d2) den ssh logins Bei d1) funktioniert's wie gehabt (und erwuenscht), bei d2) NICHT Was soll dieses Verhalten mit der bash man page (bzw. dem, was da drin steht) zu tun haben??? Ich vermute mal, GAR NIX! On Tue, 24 Oct 2006, Marc Schröder wrote: > man bash > > When bash is invoked as an interactive login shell, or as a > non-interactive shell with the --login option, it first reads and > executes commands from the file /etc/profile, if that file exists. > After reading that file, it looks for ~/.bash_profile, ~/.bash_login, > and ~/.profile, in that order, and reads and executes commands from the > first one that exists and is readable. The --noprofile option may be > used when the shell is started to inhibit this behavior. > > When a login shell exits, bash reads and executes commands from the file > ~/.bash_logout, if it exists. > > When an interactive shell that is not a login shell is started, > bash reads and executes commands from /etc/bash.bashrc and > ~/.bashrc, if these files exist. This may be inhibited by using the > --norc option. The --rcfile file option will force bash to read and > execute commands from file instead of /etc/bash.bashrc and ~/.bashrc. > > > marc@host:~$ cat .profile > # ~/.profile: executed by Bourne-compatible login shells. > > if [ -f ~/.bashrc ]; then > . ~/.bashrc > fi > > #PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 > #export PATH > > mesg n > > > > cu mb > > > Holger Rauch wrote: > > Hallo, > > > > ich habe bei einem neu aufgesetzten Testing (Etch) System das Problem, daß > > nach einem ssh login die .bash_profile und die .bashrc im HOME-Verzeichnis > > eines Benutzers nicht mehr gesourced werden. > > > > Wenn ich auf diesem neu installierten System von einem user mittels > > "su - <user_name>" auf einen anderen user wechsle, werden .bash_profile und > > .bashrc wie erwartet gesourced. > > > > Bei einem System, das ich seit geraumer Zeit von Sarge auf Etch upgedated > > habe, gibt es dieses Problem interessanterweise NICHT (zumindest hab ich es > > bis jetzt noch nicht bemerkt). > > > > Meine ersten Verdächtigen waren die SSH-Konfiguration (server- und > > client-seitig) bzw. die PAM-Konfiguration. Allerdings konnte ich da erstmal > > nix feststellen. In den README.Debian files zu den PAM packages konnte ich > > ebenfalls nix finden. > > > > Offensichtliche Fragen: > > > > - Woran liegt es, daß nach ssh logins auf einem neu hochgezogenen > > Etch-/Testing-System die .bash_profile/.bashrc im HOME-Verzeichnis eines > > Benutzers nicht mehr gesourced werden? > > > > - Was muß man an welchen config files ändern, um das "alte" Verhalten > > (Berücksichtigung von benutzer-spezifischen .bash_profile/.bashrc files) > > wieder herzustellen? > > > > Vielen Dank im Voraus für die Info! > > > > Gruß, > > > > Holger > > -- > > GPG key: 0x965D2902 > > GPG key fingerprint: 3FE8 7472 2637 2993 6BD7 015E 6E25 6D5A 965D 2902 > > > -- > Haeufig gestellte Fragen und Antworten (FAQ): > http://www.de.debian.org/debian-user-german-FAQ/ > > Zum AUSTRAGEN schicken Sie eine Mail an debian-user-german-REQUEST@lists.debian.org > mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org (engl) > -- GPG key: 0x965D2902 GPG key fingerprint: 3FE8 7472 2637 2993 6BD7 015E 6E25 6D5A 965D 2902
Attachment:
signature.asc
Description: Digital signature