On that point, I see an awful lot of code that uses dotslash as if it was necessary for files in the current directory.

You only need to prepend dotslash to a filename in order of disambiguate invocations of executables in the the current directory (and not a subdirectory).

This is because bare commands will be looked up in $PATH, rather than among executable files in $PWD.

It strikes me as weird copycat (without understanding) programming to just have it wherever you're referring to a local file. In fact I prefer to invoke `bash foo.sh` rather than `mv foo.sh foo; chmod +x foo.sh; ./foo.sh`. (This assumes that I don't need to rely on something special in the shebang line.) This also lets you use tab-completion as normal, as well as adding flags for bash like -x.

(I know you could use it for clarity when an argument could look like a string or a file, but I don't think that's usuaully the purpose.)

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!

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.

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

It makes tab completion work.

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.