3 ms·
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
by Y_Y 1y ago
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.)
- mjw1007 1y agoIt makes tab completion work.
- jagged-chisel 1y agoAt 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.
- alganet 1y agoLet'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.
- aidos 1y ago./<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.
- lynx97 1y agoFor executables, it is actually necessary to prepend ./ iff . is not in $PATH. And . is usually not in $PATH for security reasons.
- teddyh 1y agoSimilarly, many people needlessly append a slash to every directory name.
- BoredPositron 1y agoFor me it's because of rsync.
- chuckadams 1y agoIt'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.
- SoftTalker 1y agoMakes 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.
- Bleibeidl 1y agoI'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.
- amonith 1y agoI 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.
- PhilippGille 1y agoOne 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.
- Y_Y 1y agoThanks, 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.
- zahlman 1y agoThis 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".
- School-Cotton 1y agoThis is one of the papercuts of go that I find way more annoying than is rational.
- catlifeonmars 1y agoThat’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
- PhilippGille 1y ago> 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.