Tilde (~) innerhalb des Arbeitsverzeichnisses von Unix


22

Ich arbeite in einer UNIX-Umgebung und habe festgestellt, dass sich in meinem Arbeitsverzeichnis, das kilometerweit von meinem UNIX-Zuhause entfernt ist, ein befindet ~.

Jetzt, in der Vergangenheit, habe ich rm -rf ~mein Arbeitsverzeichnis gelöscht und musste die IT einbeziehen.

Ich möchte es nicht noch einmal tun. Gleichzeitig möchte ich wissen

  1. Warum wird ~in meinem Arbeitsverzeichnis erstellt? Ist es ein fehlerhafter Fingerabdruck beim Speichern ( :w!aber was passiert :w~? !!)

  2. Vor dem Einchecken gibt es ein Skript, das nach zusätzlichen Dateien oder Ordnern sucht, die p4 nicht kennt. Daher kann dies ~zu einem Problem führen. Wie kann ich also das ~aus meinem Arbeitsverzeichnis entfernen und gleichzeitig mein Zuhause nicht löschen?

Ich habe einen Sicherungsbefehl namens del, den ich anstelle von verwende rm -rf. Es werden nur Dinge an einem temporären Ort abgelegt. Ich könnte das gebrauchen und das loswerden ~. Aber ich bin mehr daran interessiert zu wissen, warum dies passiert und wie ich es entfernen kann.


Normalerweise ersetzt die Shell ~ am Anfang eines Pfads durch Ihr Ausgangsverzeichnis. Verwenden Sie den vollständigen Pfad, /home/yourUserName/~um auf das aufgerufene Verzeichnis zuzugreifen ~.
Jofel

Und ~ otheruser / file kann verwendet werden, um der Vollständigkeit halber auf die Home-Verzeichnisse anderer Benutzer zu verweisen.
Godlygeek

Sieht aus wie ein Streich!
Xolve

Antworten:


36

Entweder zitiere es:

rm -i '~'
rm -i "~"
rm -i \~

Oder referenzieren Sie es durch einen Pfad anstelle eines Basisnamens:

rm -i ./~
rm -i /path/to/~

Beachten Sie, dass dies, obwohl es sich um einen komisch aussehenden Einzelzeichennamen handelt, konzeptionell nicht anders ist, als wenn Sie eine Datei mit dem Namen " SOME$PATHdoing" erstellt hätten

touch 'SOME$PATH'

Und versucht, es zu entfernen, indem Sie tun:

rm -i SOME$PATH

( Achtung: Die Variable SOME$PATH wird im vorliegenden Beispiel nicht in Anführungszeichen gesetzt. Normalerweise wird sie in Anführungszeichen gesetzt. 'SOME$PATH' )

In beiden Fällen erweitert die Shell den von Ihnen angegebenen Namen, und Sie müssen dies verhindern.

Außerdem: Nicht rm -rfzum Entfernen einer Datei verwenden! Der gesamte Zweck von rm -rbesteht darin, anzugeben, dass rmes in Ordnung ist, Verzeichnisse zu entfernen. Wenn Sie nicht versehentlich ganze Verzeichnisse entfernen möchten, während Sie versuchen, Dateien zu entfernen, sollten Sie dies nicht für gewöhnlich tun -r!


12
Ich habe das gerade getestet. :w~in vim hat eine Datei namens erstellt ~. rm ~zurückgekehrt cannot remove /home/seth it is a directory. rm "~"habe die Datei entfernt . Nur um zu unterstreichen , vergehen Sie nicht -rfautomatisch .
Seth

4
+1 für die Empfehlung, gewalttätige Optionen standardmäßig wegzulassen. Dies entspricht der kill -9Standardeinstellung, die ich gesehen habe.
Celada

Ich sehe, dass das Beispiel rm -i $FOOdie Variable aus Gründen des Beispiels absichtlich nicht zitiert, aber dennoch: Das Zeigen eines Shell-Beispiels mit rmund einer nicht zitierten Variablen als Argument ist SEHR SCHLECHT , ähm, sorry, unabhängig vom Kontext. Ich bin sicher, das kann sogar bewiesen werden :) Ich füge noch eine Anmerkung hinzu - aber vielleicht könntest du das Beispiel ein wenig ändern?
Volker Siegel

@VolkerSiegel, Point taken - Ich habe an Ihrer Bearbeitung teilgenommen, aber die Fußnote schien etwas zu schwerfällig. Ich bin auch auf einen Variablennamen umgestiegen, der mit noch geringerer Wahrscheinlichkeit Probleme verursacht - die meisten Leute haben keine Datei mit einem Namen SOME/bin:/usr/binirgendwo in ihrem Dateisystem. :)
Godlygeek

Ja, sieht gut aus! (Ich wollte fast antworten: Was? Schwerfällig? Hattest du jemals ein echtes Zitatproblem in deinem Leben?) Nur ein bisschen verzweifelt über die Menge falscher Shell-Beispiele da draußen im Allgemeinen ... Hey, es ist schwer auch ohne falsche beispiele zu verstehen! )
Volker Siegel

1

Die Tilde ls ~listet, wenn sie alleine im Kontext von verwendet wird, Ihr Heimatverzeichnis als ~ auf und ist eine Verknüpfung zu Ihrem Heimatverzeichnis. Wenn Sie dies getan haben, werden ls ~brownSie den Inhalt von Browns Heimatverzeichnis auflisten.

VIM erstellt, sofern nicht anders angegeben, eine Sicherungskopie einer geänderten Datei: myFile myFile ~.

Dieses Verhalten ist gut, da es eine Sicherungskopie erstellt. Wenn Sie es jedoch nicht möchten, fügen Sie Ihrer .vimrc-Datei Folgendes hinzu: Legen Sie keine Sicherungskopie fest (auf die ich gerade zugegriffen habe vi ~/.vimrc).

Und natürlich, wie andere gesagt haben, wenn Sie eine Datei mit dem Namen ~ haben, dann entkommen Sie dem Zeichen einfach als \ ~

me 217 % vi this      (saved as :w~)
me 218 % ls
this  ~
me 219 % cat \~
kfdkdfk
me 220 % \rm \~
me 221 % ls
this

0

Dies kann durch Tippfehler geschehen. Wenn Ihre TERM=xtermKonfiguration meiner ähnelt, sendet praktisch jede Funktionstaste auf Ihrer Tastatur Escape-Sequenzen wie ...

infocmp -1 | grep -n \~ | tail -n3
138:    kich1=\E[2~,
141:    knp=\E[6~,
142:    kpp=\E[5~,

Mehr als die Hälfte der Ausgabe von infocmp -1Contained ~Tilde entweicht auf meinem Computer - und ich verstehe nicht, was die meisten von ihnen tun. Ich weiß, dass zshzumindest der entkommene Teil der Zeichenfolge in den meisten Fällen tatsächlich gegessen wird - und nur die ~Tilde übrig bleibt .

Wenn Sie zum Beispiel echodann <space>dann tippen F6und <return>drucken ...

/home/mikeserv

Die tatsächlich gesendete Escape-Sequenz lautet ...

kf6=\E[17~

Interessanterweise gibt es noch andere dieser Escape-Sequenzen, die >Zeichen enthalten .

infocmp -1 | grep \>
is2=\E[!p\E[?3;4l\E[4l\E>,
rmkx=\E[?1l\E>,
rs2=\E[!p\E[?3;4l\E[4l\E>,

Dies sind häufig verwendete Escape-Zeichenfolgen - Zurücksetzen und Initialisieren. Es ist nicht schwer vorstellbar, dass eine heruntergefallene Tastatur oder ein Knopfdruck, wenn eine interaktive Shell auf die Eingabe wartet, zu zufällig abgeschnittenen ~Dateien in Ihrem gesamten Dateisystem führen kann. Zumindest taucht es gelegentlich bei mir auf.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.