One issue is when the path is not interpreted by the shell but by a program which plays by different rules.

For example in Go:

  $ cd /path/to/go/repo
  $ go run cmd/myapp
  package cmd/myapp is not in std (/usr/local/go/src/cmd/myapp)
  
  $ go run ./cmd/myapp
  Hello, World!

And then people don't want to think about when your path is for the shell and when it's a CLI param and how the CLI treats it, and just use the version that always works.

Thanks, this is the first good reason I've seen! Seems crazy to me that the go tool does that, but maybe I just lack sufficient unix-nature.

This allows it to disambiguate between system path syntax and the language's syntax for symbolic names.

Similarly, package installers can use this to disambiguate between "install the local file with this exact name" and "look up a file on the index for the named package".

This is one of the papercuts of go that I find way more annoying than is rational.

That’s because cmd/myapp is not a local path, it’s a universal path. It makes more sense when you type go run github.com/user/name/cmd/myapp

> cmd/myapp is not a local path, it’s a universal path

In `go run` the CLI interprets it as universal path, to be precise. That's exactly the point.

> go run github.com/user/name/cmd/myapp

That's not an alternative when you're working on the app's code locally. You have to use `./cmd/myapp`.

And when you do that multiple times per day/week, after a while you just start always using `./` prefix for local paths.

Would it be preferable to use a URI for go run?

For example

- go run go://cmd/foo

- go run file:///cmd/foo

I'm pretty sure most people use it to make clear it's a relative path. It takes mental load off the one reading the code. That's why I pretty much always use it, not only when executing things.

./<tab> completes nicely. Ambiguity is removed. There’s no chance of accidentally running the wrong executable.

So I think you and I differ on this one, but none of this is a hill I care to die on.

I use it for autocomplete... e.g ./f<tab> and enter. If I don't do it the terminal literally hangs for a split second and gives me a lot useless suggestions. I rarely type full words.

Similarly, many people needlessly append a slash to every directory name.

For me it's because of rsync.

It's handy when the directory might not exist, happens all the time in git checkouts. Raise your hand if you've ever moved something to tmp and created a file called tmp.

Usually it's tab-complete adding the slash though, I don't go typing it in.

Makes it clear you're naming a directory and not a file.

I also alias 'ls' to 'ls -F' so that directories have a / appended, makes it easier to understand the output.

It makes tab completion work.

At the start of a line? So you want to run a script or executable in the current directory. PATH doesn’t contain . and ./ is necessary.

As an argument in a line? My shell offers completion from the current directory without ./ just fine.

Let's say you have 100 programs in your PATH that start with the letter "g", but only one program in the current folder that starts with "g". You type `./g[TAB]` so it autocompletes automatically to the local program instead of cycling through dozens of results you know you don't want.

For executables, it is actually necessary to prepend ./ iff . is not in $PATH. And . is usually not in $PATH for security reasons.