staging.inyokaproject.org

So hab mal was kleines über die bashrc-Datei geschrieben und was man mit ihr machen kann: Baustelle/Bash/bashrc

greets

Zum Abschnitt "Stellt die bashrc eine Gefahr dar?" Man kann den .bashrc Besitzer ändern wie man will, wenn ich einem Verzeichnis Schreibrechte hab, und das setzte ich mal voraus in meinem eigenem $HOME, dann kann ich die Datei auch löschen (und vorher kopieren und mit verändertem Inhalt wieder neu anlegen). In einem Wort zusammengefasst: sinnlos

Sehr schöner Artikel.

Mir ist nur aufgefallen das extract eigentlich schön ist aber unp besser ist 😉

gruß
Adrian

@comm_a_nder: Ahh danke stimmt löschen kann man sie ja immernoch dann... Ich hab den Workaround jetzt durch Setzen der immutable-Flag beschrieben, das sollte sicher sein.
@AdrianB: Ist ja auch nur ein Beispiel 😉 Aber eines was ich auch nutze und es ist bestimmt kleiner als unp.

greets

Adna rim hat geschrieben:

@AdrianB: Ist ja auch nur ein Beispiel 😉 Aber eines was ich auch nutze und es ist bestimmt kleiner als unp.

minimal, da unp "nur" ein Perl-Skript ist, dafür aber mehr Funktion hat, auf jeden Fall ist beides kleines als Fileroller oder Xarchiver 😀

gruß
Adrian

Ich schau mir unp mal an 😉 , alleine schon aus dem Grund weil wir keinen Wiki-Artikel darüber haben 😀

So ich habe noch ein paar Veränderungen am bashrc-Artikel vorgenommen damit man das mit der bash_profile besser peilt und werde wenn ich verschiebe dann eine Weiterleitung von Bash/bash_profile auf Bash/bashrc setzen.

greets

Hi
Die Diskussionsbox fehlt.
Außerdem stimme ich Adrian zu, extract ist wirklich eher ein unglückliches Beispiel. Imho reicht up als Beispiel aus.
Und: Woher nimmst du die Daten, wieviele die .bashrc für gefährlich bzw ungefährlich halten? comm_a_nder hat übrigens recht, Löschen geht anscheinend immer. chattr -i bewahrt vor dem Löschen nicht.
Der einzige Weg, hier einen Schutz zu gewährleisten, wäre wohl das permanente Überwachen der .bashrc.
Gruß

chattr +i schützt vor dem Löschen:

48bash:~/Desktop$ touch test
51bash:~/Desktop$ sudo chattr +i test
00bash:~/Desktop$ rm test
rm: reguläre leere Datei (schreibgeschützt) „test“ entfernen? y
rm: Entfernen von „test“ nicht möglich: Operation not permitted
04bash:~/Desktop$ echo 'Schreibtest' > test
bash: test: Permission denied
46bash:~/Desktop$ sudo chattr -i test
08bash:~/Desktop$ rm test
10bash:~/Desktop$

Wie gesagt extract ist nur ein Beispiel, was man mit der bashrc anstellen kann und da extract wirklich einen guten und sinnvollen Nutzen bringt halte ich es für ein gutes Beispiel.

greets

Mit dem Löschen hast du recht, ich hatte - statt + gesetzt. Kopf ->Tisch.

Was transportiert extract, was das "up n" Beispiel nicht transportiert? ☺
Ich möchte dir nicht dein Beispiel madig machen. Aber es wäre kürzer und einfacher, wenn stattdessen geschrieben würde: "'Up N' würde man aslo so in die .bashrc schreiben:

function up { 
...
} 

Das Problem bei extract ist, dass die Dateiendungen doch beliebig verändert werden könnten. Das ist im Privatgebrauch nicht so schlimm, kann man ja drauf achten, aber muss so nicht ins Wiki. Unp hast du doch schon entdeckt 😉
Gruß

Ja unp ist imo auch besser. Ich denke mir nur, dass Linux-Neulinge nicht so sehr den Sinn hinter up N blicken, obwohl ich das auch benutze und für sehr nützlich halte. Bei extract() erkennt man doch leichter, was es macht und wie nützlich es auch für den Durchschnittsuser sein kann. Also ich will mit dem Beispiel halt zeigen, dass man sehr nützliche Skripte in die bashrc integrieren kann und befürchte, dass es viele User bei up N nicht blicken.

greets

Habe extract nun rausgenommen und nach Bash/bashrc verschoben.

greets

Hm...
Man sollte darauf hinweisen, das sämtliche Dateien, die beim Login bzw. Logout ausgelesen werden potentiell gefährlich sein können.
Das wären u.a.:

~/.bashrc
~/.bash_logout
~/.profile
~/.xsession bzw. ~/.xinit

, sowie sämtliche Dateien, die von den oben genannten ausgeführt/eingebettet werden.

Außerdem müssen dazu noch Dateien von den Windowmanagern gezählt werden. Das wäre z.B:

~/.fluxbox/startup
~/.fluxbox/menu
~/.fluxbox/keys

Desweitern müssen sämtliche ausführbaren Dateien in $HOME dazugezählt werden.

Meiner Meinung nach wäre es besser einen Artikel "Absichern des Homeverzeichnisses" zu verfassen, und auf diesen zu verweisen.

Anwendungsbeispiel PROMPT_COMMAND hinzugefügt.

Dies hat diesen nützlichen Effekt:

$ false
*** Fehlercode: 1 ***
$ ! false
$ echo $?
0
$

Wer ausgiebig Skripte entwickelt und testet, spart sich die Eingabe etlicher echo $?.

sehr schön, hab ich gleich mal umgesetzt. Danke.