SmartJoin incorrectly treats relative paths containing special variable names as special paths

[znnnnnnn-wil]

Description

SmartJoin incorrectly treats ordinary relative paths containing special variable names such as .ROOT_DIR as absolute/special paths, causing them to bypass the base-directory join.

What did you do?

I called SmartJoin with a normal relative path whose directory name happens to contain one of the special variable names:

SmartJoin(base, filepath.Join("project.ROOT_DIR", "file.txt"))

A minimal regression test demonstrating the issue is:

func TestSmartJoinRelativePathContainingSpecialVariableName(t *testing.T) {
	base := filepath.Join("base", "dir")
	path := filepath.Join("project.ROOT_DIR", "file.txt")

	got := SmartJoin(base, path)
	want := filepath.Join(base, path)

	if got != want {
		t.Fatalf("SmartJoin() = %q, want %q", got, want)
	}
}

It can be run with:

go test ./internal/filepathext -run TestSmartJoinRelativePathContainingSpecialVariableName -count=1

What did you expect to happen?

The path should be treated as a normal relative path and joined with base.

In other words:

SmartJoin(base, filepath.Join("project.ROOT_DIR", "file.txt"))

should return the same result as:

filepath.Join(base, "project.ROOT_DIR", "file.txt")

What happened instead?

SmartJoin returns the input relative path unchanged instead of joining it with base.

The same behavior also appears to affect relative path components containing:

• .ROOT_DIR
• .TASKFILE_DIR
• .USER_WORKING_DIR

From looking at the implementation, this may be caused by isSpecialDir using strings.Contains to detect special variables. As a result, an ordinary directory name containing one of these strings can be matched even when the variable is not actually part of a {{ ... }} template expression.

This can cause normal relative paths to bypass the base-directory join and potentially be resolved relative to an unintended location, including paths used for task directories, includes, dotenv files, or fingerprint-related logic.

Version

main (385e5ad)

Operating system

Windows amd64, Go 1.26.5

Experiments Enabled

None

[trulede]

@znnnnnnn-wil Please explain why this causes you a problem. What are you trying to do?

[znnnnnnn-wil]

Thanks for asking. I found this while looking into path resolution rather than from a crash.

The concrete case I'm trying to support is an ordinary relative directory whose name happens to contain one of these special-variable strings, without actually using it as a Task template variable.

For example, a project could contain:

project/
├── Taskfile.yml
└── project.ROOT_DIR/
    └── .env

with:

version: '3'

dotenv:
  - project.ROOT_DIR/.env

Here, project.ROOT_DIR is just a literal directory name. I would expect the dotenv path to be resolved relative to the Taskfile directory.

After template replacement, taskfile.Dotenv passes this path to SmartJoin(dir, dotEnvPath). Because isSpecialDir currently detects .ROOT_DIR using a substring match, this ordinary relative path is treated as special and returned without being joined to dir.

This becomes observable when the Taskfile directory and the process working directory are different. In that case, the dotenv file may be looked up relative to the wrong directory instead of relative to the Taskfile.

So the issue is not that I am trying to use .ROOT_DIR as a variable here. It is that a literal file or directory name containing that substring changes the path-resolution behavior.

[trulede]

I know the code behind this (too well), at that the problem you identify exists.