Hacker News Reader

Comment by ericholscher | Hacker News Reader

Isn’t that true of command execution as well? I guess you could use a full path to the pip executable, but similar issue.

View on HN

Only if PATH includes ".", which is why they say not to do that (or use windows. I'm not sure if you can fix that there).

CMD includes the CWD in the PATH,[a] but PowerShell doesn’t; you’re forced to do the `./` (or `.\`) dance.

However, if you tab complete a file name that’s not "dot slash" prefixed, it’ll add it for you. Not sure if sh and friends do that.

[a]: Implicitly. Echoing the $PATH variable won’t include `.`, but you can execute as if it was

Even if PATH includes the current directory, you'll be safe as long as it doesn't take priority over the regular bin directories.

Do you mean there might be a 'pip' command in the local directory that might get called by accident, or do you mean the real python pip command might load a python module from the local directory by accident?

The second thing. Python includes the current working directory first in the module search path. It leads to the above issue and occasionally some a tricky debugging problem.

If you run a script, such as "pip", sys.path[0] is the script's directory, not cwd:

https://docs.python.org/3/using/cmdline.html

> If the script name refers directly to a Python file, the directory containing that file is added to the start of sys.path

You are right! I missed the switch from talking about the `python -m`-style invocation versus the `python <script>`-style invocation.

(Should I double down and attribute it to difficulties with how significant whitespace indentation can make it hard to determine the scope (of the comment threading on mobile)? :P)

Windows' cmd.exe is the only shell I'm aware of that (by default) checks the local directory for executables before the actual PATH variable, so I wouldn't consider that a real problem.

The 'local directory' one is the actual concern. For example, our CI system for one of our tools runs commands like `pip install -U setuptools`. If we switched it to `python -m pip install -U setuptools`, it would continue to work fine - unless a developer accidentally committed a file called `pip.py` to the root.

At that point, Python would try to import `pip.py` as `pip` instead of the actual module pip (because current directory is checked for includes first).

Did you reply to the right comment? I was looking for clarification on a comment made when discussing running pip directly, as a full path to the pip executable, and not via "python -m pip ...".

Reply on news.ycombinator.com