Go Equivalent of __dirname: Getting the Current File or Working Directory in Golang

By the end of this page, you will understand the difference between a source file location, the current working directory, and the executable location in Go. You will also learn when runtime.Caller is appropriate, why it is usually not the idiomatic replacement for Node.js __dirname, and which Go APIs are better depending on what you are actually trying to do.

In Go, there is no exact built-in equivalent to Node.js __dirname.

That is because Go programs are usually compiled into binaries, and once compiled, the source file path is often not the thing you want at runtime.

The three different paths people often confuse

When developers ask for the “current file directory,” they usually mean one of these:

1. The source file's directory

   • Where the .go file lives on disk.
   • This is what runtime.Caller can tell you.
   • Useful in limited cases, mostly debugging or special development-time tooling.

2. The current working directory

   • The directory from which the program was started.
   • Retrieved with os.Getwd().
   • Common for reading config files, relative paths, and CLI tools.

3. The executable's directory

   • Where the compiled binary is located.
   • Retrieved with os.Executable().
   • Useful when shipping an app with files next to the binary.

Why this matters

In Node.js, __dirname is tied to the module file being executed. In Go, runtime code is typically not written around source-file-relative paths, because the binary may run on another machine where the original source files do not exist.

So the idiomatic Go answer depends on your goal:

Think of a Go program like a traveler with three different addresses:

• Home address = source file directory
• Current location = working directory
• Hotel address = executable directory

If you ask, “Where am I?” the answer depends on what you really mean.

runtime.Caller() tells you the home address of the source code. os.Getwd() tells you the current location. os.Executable() tells you the hotel address where the binary is staying.

Most runtime tasks care about the current location or the hotel address, not the original source file.

1. Get the current working directory

Use this when your program should read files relative to where it was started.

package main

import (
	"fmt"
	"os"
	"path/filepath"
)

func main() {
	wd, err := os.Getwd()
	if err != nil {
		panic(err)
	}

	filePath := filepath.Join(wd, "data.csv")
	fmt.Println("Working directory:", wd)
	fmt.Println("File path:", filePath)
}

os.Getwd() returns the current working directory.

2. Get the executable's directory

Use this when your program ships with files next to the binary.

package main

import (
	"fmt"
	"os"
	"path/filepath"
)

func main() {
	exePath, err := os.Executable()
	if err != nil {
		panic(err)
	}

	exeDir := filepath.Dir(exePath)
	filePath := filepath.Join(exeDir, "data.csv")

	fmt.Println("Executable path:", exePath)
	fmt.Println(, exeDir)
	fmt.Println(, filePath)
}

Consider this example:

package main

import (
	"fmt"
	"path/filepath"
	"runtime"
)

func main() {
	_, filename, _, ok := runtime.Caller(0)
	if !ok {
		panic("could not get caller info")
	}

	dir := filepath.Dir(filename)
	file := filepath.Join(dir, "data.csv")

	fmt.Println("filename:", filename)
	fmt.Println("dir:", dir)
	fmt.Println("file:", file)
}

What happens step by step

1. runtime.Caller(0) asks Go for information about the current function call.

   • 0 means “this function itself.”
   • 1 would mean the caller of this function.

2. It returns several values:

   • program counter
   • filename
   • line number
   • success flag

3. filename might be something like:

/home/user/project/main.go

Using os.Getwd()

Common in:

• CLI tools that read files from the current folder
• scripts run from a project directory
• local development commands like go run .

Example:

• A CSV importer that expects ./data.csv
• A config loader that reads ./config.json

Using os.Executable()

Common in:

• desktop apps
• self-contained command-line binaries
• deployed services that keep templates or assets near the binary

Example:

• A binary in /opt/myapp/ that loads /opt/myapp/config.yaml

Using runtime.Caller()

Common in:

• debugging and logging utilities
• test helpers
• development tools that need source file metadata
• locating test fixtures relative to test source files

Example:

• A test file loading testdata/sample.json from the package directory

Using

In real Go codebases, developers usually avoid hard-coding logic around source file paths for application runtime.

Common patterns

1. Working-directory based loading

func loadConfig() ([]byte, error) {
	return os.ReadFile("config.json")
}

This is simple and common for command-line tools.

2. Executable-relative loading

func configPath() (string, error) {
	exe, err := os.Executable()
	if err != nil {
		return "", err
	}
	return filepath.Join(filepath.Dir(exe), "config.json"), nil
}

This is common in packaged applications.

3. Embedded assets

package main

import _ "embed"

//go:embed data.csv
var csvData []byte

This avoids filesystem path issues entirely.

1. Using runtime.Caller when you really want the working directory

Broken idea:

_, filename, _, _ := runtime.Caller(0)
filePath := filepath.Join(filepath.Dir(filename), "config.json")

Why this can be wrong:

• It ties runtime behavior to source code layout.
• The source files may not exist where the binary runs.

Use os.Getwd() or os.Executable() depending on intent.

2. Using path instead of filepath

Broken or non-idiomatic:

import "path"

Better:

import "path/filepath"

Use filepath for local filesystem paths.

3. Ignoring errors

Broken code:

_, filename, _, _ := runtime.Caller()
wd, _ := os.Getwd()

path vs filepath

Quick reference

Current working directory

wd, err := os.Getwd()

Executable path

exe, err := os.Executable()
dir := filepath.Dir(exe)

Source file path

_, filename, _, ok := runtime.Caller(0)
dir := filepath.Dir(filename)

Join file paths

filepath.Join(dir, "data.csv")

Rules of thumb

• Want paths relative to where the command runs? Use os.Getwd().
• Want paths relative to the binary? Use os.Executable().
• Want the .go source file location? Use runtime.Caller().
• For local filesystem paths, prefer filepath over path.
• Always check errors.
• If the file should ship inside the program, consider embed.

Edge case reminder

runtime.Caller() depends on source file information and is not the general replacement for Node.js .

Is runtime.Caller() the Go equivalent of __dirname?

Not exactly. It can give you the source file path, which is similar in spirit, but it is not usually the main runtime solution in Go.

What is the idiomatic way to open a file in Go?

It depends on where the file is expected to be:

• use os.Getwd() for working-directory-relative files
• use os.Executable() for executable-relative files
• use embed for bundled files

Should I use path.Join or filepath.Join in Go?

Use filepath.Join for filesystem paths. path.Join is mainly for slash-separated paths such as URLs.

Why does os.ReadFile("data.csv") sometimes fail?

Because relative paths are resolved from the current working directory, which may not be the same as your source file directory.

When is runtime.Caller() a good choice?

It is useful for debugging, logging, tests, and tools that need source code location information.

What if I want to include a CSV or template file inside the program?

Use the package if possible. It removes the need to locate files on disk at runtime.

• os.Getwd — gets the current working directory.
• os.Executable — gets the path to the running binary.
• path/filepath — builds filesystem paths correctly across operating systems.
• runtime.Caller — provides source file and line information.
• embed — includes static files directly in the binary.
• file I/O in Go — needed when opening, reading, and handling files.
• error handling in Go — important because path lookup functions can fail.