Every now and then I see some command to run a shell script that looks something like this:


Now, I know that in general you need a ./ to tell Linux to look in your current directory for executables. But what's the point of saying "go to this folder, then go there again, then execute a file?"

  • 11
    It isn't wrong, but it is redundant. Is it possible that the path was autogenerated in the scripts where you see this? – Fox Apr 1 '17 at 18:36
  • 7
    almost definitely the automated result of pasting a directory and a filename with the leading ./ -- it's a feature, not an accident, that this results in a valid path construct – cat Apr 1 '17 at 20:20
  • 1
    Interestingly enough is there any overhead in having the ./ there? What if there were several hundred chained together? Or thousands. Is the OS or interpreter smart enough to ignore or truncate them? – Mike McMahon Apr 1 '17 at 23:46
  • @MikeMcMahon Not sure how the final part of the path parser is implemented, but i expect either no-change operations in a state machine or skip-this operations in a tree builder; so i would think that it would sum down to the cost of "if ".", NEXT". – StarWeaver Apr 2 '17 at 3:11
  • @MikeMcMahon If you're not already making pathnames one character long as a necessary optimization, I'd say you shouldn't worry about it. All processed data has a cost, both memory and computation: that extra ./ takes up a couple extra bytes, and any work done on the path must iterate/loop over those bytes and do at least one logical comparison on them. Some cost goes into the decision and actions needed to ignore/truncate. But I think the realistic cost is a handful of CPU instructions, branch predictor misses, and a few bytes of memory and CPU cache, on average. Still extremely negligible. – mtraceur Apr 2 '17 at 6:12

There is no difference. Executing the following:




will have the same effect.

  • 2
    This is also the case with '//' in a path. I've done that in scripts by accident as well. – user208145 Apr 1 '17 at 21:48
  • 1
    not if script.sh parses $0... – RiaD Apr 1 '17 at 22:27
  • 1
    @user208145 Unless the // is at the start of the path. I believe that causes it to be treated as a network path. – JAB Apr 2 '17 at 1:37
  • 1
    @JAB only in cygwin, afaik, linuxdom doesn't use that. – StarWeaver Apr 2 '17 at 3:08
  • @StarWeaver Ah, you're right. I was thinking of superuser.com/a/389345/45130, which just says that some shells preserve those paths to be compatible with that behavior. – JAB Apr 2 '17 at 3:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.