Arbeitsverzeichnis in R: setwd(), getwd() und den Workspace leeren

Was das Arbeitsverzeichnis ist

Jede R-Sitzung läuft "in" genau einem Ordner: dem Arbeitsverzeichnis. Wann immer du einen relativen Pfad nutzt - einen Pfad, der nicht an der Wurzel des Dateisystems beginnt -, löst R ihn gegen diesen Ordner auf. read.csv("data.csv") bedeutet nicht "finde data.csv irgendwo auf meinem Computer", sondern "öffne die Datei namens data.csv im Arbeitsverzeichnis".

Diese eine Tatsache erklärt den häufigsten Anfängerfehler in R:

read.csv("data.csv")
# Error in file(file, "rt") : cannot open the connection
# In addition: Warning message: cannot open file 'data.csv': No such file or directory

Die Datei existiert - nur nicht in dem Ordner, in den R gerade schaut. Mit deinem read.csv-Aufruf stimmt alles; das Arbeitsverzeichnis der Sitzung und der Ort der Datei sind sich uneins. Die beiden Funktionen unten machen daraus statt eines Rätsels eine Zehn-Sekunden-Diagnose.

getwd() und setwd()

getwd() (get working directory) sagt dir, wo R gerade sucht:

print(getwd())

Führ das aus, und du siehst einen absoluten Pfad - den Ordner, in dem diese Sitzung verankert ist. setwd() (set working directory) ändert ihn:

setwd("C:/Users/rosa/projects/sales-analysis")   # Windows: use / not \
setwd("/Users/rosa/projects/sales-analysis")     # macOS / Linux
getwd()                                          # confirm it took

Zwei technische Anmerkungen. Unter Windows schreibst du Pfade mit / (oder verdoppeltem \\) - ein einzelnes \ ist in R-Zeichenketten ein Escape-Zeichen, also ist "C:\Users" ein Syntaxfehler. Und setwd() scheitert sofort, wenn der Ordner nicht existiert, was der freundlichste Fehlschlag ist, den du den ganzen Tag bekommst: Es kann dich nicht still am falschen Ort abstellen.

Die Debugging-Routine für jeden "cannot open file"-Fehler lautet daher: getwd(), um zu sehen, wo R sucht, und das dann mit dem Ort vergleichen, an dem die Datei tatsächlich liegt.

list.files(): sehen, was R sieht

Das dritte Werkzeug im Kasten listet den Inhalt des Arbeitsverzeichnisses auf - buchstäblich die Menge der Namen, die ein relativer Pfad erreichen kann:

print(list.files())

Taucht die Datei, die du lesen willst, in dieser Ausgabe auf, wird read.csv("thatfile.csv") sie finden. Tut sie es nicht, hilft kein noch so häufiges Neutippen der read.csv-Zeile - das Arbeitsverzeichnis ist das, was zu korrigieren ist. list.files("data") schaut in einen Unterordner, und list.files(pattern = "\\.csv$") filtert nur auf CSVs. Wenn ein Dateiname richtig aussieht, aber nicht gefunden wird, legt list.files() auch die klassischen Übeltäter offen: eine unsichtbare, von einem Texteditor angehängte .txt-Endung oder Data.csv vs. data.csv auf einem Dateisystem mit Groß-/Kleinschreibung.

Warum fest verdrahtetes setwd() bricht

Nun der meinungsstarke Teil. Du wirst Skripte sehen, die so beginnen:

setwd("C:/Users/me/Desktop/stuff/project3/final_FINAL")

Diese Zeile funktioniert auf genau einem Rechner: dem der Autorin. Auf deinem Laptop, dem Mac deiner Kollegin, dem Institutsserver oder deinem eigenen Rechner nach einer Umsortierung scheitert sie in Zeile 1. Einen absoluten Pfad fest zu verdrahten backt die Ordnerstruktur einer Person in Code ein, der sie überleben soll.

Die Lösung dreht die Verantwortung um: Lass nicht das Skript den Ordner finden - starte R im richtigen Ordner und nutze im Skript relative Pfade. Konkret:

• Nutze RStudio-Projekte. Das Öffnen einer .Rproj-Datei setzt das Arbeitsverzeichnis automatisch auf den Projektordner, auf jedem Rechner. Im Skript funktioniert dann read.csv("data/sales.csv") für jeden, der das Projekt hat.
• Ein Start aus dem Terminal erledigt dasselbe: Rscript analysis.R nutzt den Ordner, aus dem du es startest, als Arbeitsverzeichnis (siehe R-Skripte ausführen).
• Das Paket here geht für alle, die das wollen, einen Schritt weiter - here::here("data", "sales.csv") baut Pfade von der Projektwurzel aus, egal wohin das Arbeitsverzeichnis gewandert ist -, aber Projekte plus relative Pfade decken die meisten Bedürfnisse auch ohne ab.

setwd() selbst ist nicht böse - interaktiv beim Erkunden ist es in Ordnung. Der Geruch ist speziell ein absolutes, rechnerspezifisches setwd(), das oben in einem geteilten Skript eingecheckt wird.

Der Workspace: ls() und rm()

Neben "In welchem Ordner bin ich?" steht das zweite Stück Sitzungszustand: der Workspace (die globale Umgebung) - jedes Objekt, das du in dieser Sitzung erzeugt hast. ls() listet sie auf, rm() entfernt sie:

x <- 10
y <- "hello"
print(ls())

rm(x)             # remove one object
print(ls())

rm(list = ls())   # remove everything: the "clear environment" idiom
print(ls())

Das letzte ls() gibt character(0) aus - ein leerer Workspace. Die Beschwörungsformel rm(list = ls()) liest sich seltsam, bis man sie zerlegt: ls() gibt den Zeichenvektor aller Objektnamen zurück, und rm(list = ...) löscht jeden Namen in diesem Vektor. Es ist das Code-Äquivalent zum Besen-Symbol im Environment-Bereich von RStudio.

Wisse, was es nicht tut: Mit library() geladene Pakete bleiben geladen, Optionen bleiben gesetzt, und das Arbeitsverzeichnis bleibt, wo es ist. Es leert Objekte, sonst nichts - es ist also kein Ersatz für einen Neustart von R, wenn du wirklich eine saubere Ausgangslage willst.

Die Konsole leeren und die .RData-Falle

Die Konsole zu leeren - den Rückblick auf Befehle und Ausgaben - ist kosmetisch und vom Leeren des Workspace getrennt. In RStudio ist das Strg+L; im Code sendet das schrullige cat("\014") das Seitenvorschubzeichen, das die meisten Konsolen als "Bildschirm löschen" interpretieren. Keines von beiden rührt deine Objekte an.

Schließlich die Falle. Wenn du R beendest, bietet es an, das "workspace image" zu speichern - es schreibt jedes Objekt in eine versteckte .RData-Datei, die beim nächsten Start von R in diesem Ordner still wieder geladen wird. Lehn ab und schalt es dauerhaft aus (RStudio: Tools → Global Options → "Restore .RData" abwählen, "Save workspace" auf Never setzen). Ein wiederhergestellter Workspace bedeutet, dass deine Sitzung mit Objekten von vor Tagen verschmutzt startet, erzeugt von Code, den du seither vielleicht geändert oder gelöscht hast. Dein Skript scheint zu funktionieren - weil es sich auf ein veraltetes model_v2 stützt, das nichts in der Datei mehr erzeugt - bis es auf einem sauberen Rechner läuft und zusammenbricht.

Die professionelle Gewohnheit ist das Gegenteil: sauber starten und das Skript erneut ausführen. Wenn deine Analyse ein Skript ist, das in einer frischen Sitzung von oben nach unten durchläuft, ist sie konstruktionsbedingt reproduzierbar; der Workspace ist wegwerfbare Ausgabe, nie kostbarer Zustand. Starte R häufig neu (RStudio: Session → Restart R), genau um zu beweisen, dass dein Skript weiterhin für sich allein steht.

Was du mitnimmst

• Relative Pfade lösen sich gegen das Arbeitsverzeichnis auf; getwd() zeigt es, setwd() ändert es, list.files() zeigt, was erreichbar ist.
• "Cannot open file" bedeutet fast immer, dass Arbeitsverzeichnis und Dateiordner nicht übereinstimmen - diagnostizieren mit getwd() + list.files().
• Checke nie ein absolutes setwd() in ein geteiltes Skript ein - nutze RStudio-Projekte (oder starte das Skript aus seinem Ordner) und relative Pfade.
• ls() listet Workspace-Objekte; rm(x) entfernt eines; rm(list = ls()) leert alle - Pakete und Optionen bleiben.
• Strg+L (oder cat("\014")) leert nur den Konsolentext.
• Speichere/stelle .RData nicht automatisch wieder her: sauber starten und das Skript erneut ausführen - das macht deine Arbeit reproduzierbar.

Als Nächstes: echte Daten lesen - read.csv() und Co., nun da R im richtigen Ordner sucht, um sie zu finden.