# Ein großer Fehler find$ {dir}/ -mtime +1 -exec rm -f {} ?\;



## F0rris (4. Mai 2012)

Hallo zusammen,

wie im betreff schon steht, hab ich einen lustigen Befehl in eine datei eingepflegt, welche ich mittels *sh tmp.sh* ausgeführt habe.


```
diir=/tmp
find$ {dir}/ -mtime +1 -exec rm -f {} ?\;
```

Wie man auf den ersten blick vermutet, ist das eine tolle Methode um das tmp Verzeichnis regelmäßig zu leeren. Dumm nur, wenn man die Variable falsch schreibt, wie in meinem Fall. Hier hat er angenfangen im Wurzelverzeichnis zu löschen.


```
root@server:~# df
-bash: /bin/df: No such file or directory
root@server:~# dir
-bash: /bin/dir: No such file or directory
root@server:~# ls
-bash: /bin/ls: No such file or directory
root@server:~#
```

Situation, ich hab eine aktive Verbindung via ssh aber mit weiteren komm ich nicht mehr drauf.

Nachdem die Situation eigentlich unausweiglich ist, werde ich vermutlich um eine Neuinstallation nicht rum gekommen oder?

Die Dateien im /bin sehen eigentlich vollständig aus ...  eigentlich

Beste Grüße F0rris


----------



## deepthroat (4. Mai 2012)

Hi.





F0rris hat gesagt.:


> Die Dateien im /bin sehen eigentlich vollständig aus ...  eigentlich


Wie kommst du denn an die Dateiliste, wenn kein ls mehr funktioniert?

Welche Distribution verwendest du?

Hast du direkten Zugriff oder nur Remote?

Gruß


----------



## imweasel (4. Mai 2012)

Hi,

hast du eine Möglichkeit auf dem System Dateien abzulegen? Wenn ja, dann könntest du von einem anderen System (gleiche Version usw.) den Inhalt von /bin/ dort ablegen und versuchen dieses neue Verzeichnis in deine PATH-Variable einzutragen.

Wenn du physikalischen Zugriff darauf hast, dann mit einer Live-CD anbooten, Inhalt von /bin/ von einem anderen System holen... bei einem vergleichebaren Fall hat es mir geholfen.


----------



## Navy (8. Mai 2012)

Wenn ssh funktioniert, dann auch scp.


----------

