When reading https://github.com/psf/black#where-black-looks-for-the-file, the following commands should find the same pyproject.toml file:

• black --check -v test.py
• type test.py | black --check -v -

On Linux this seems the case (with type replaced by cat), but on Windows only the first command finds the pyproject.toml file if it's in a parent folder. When I discovered this, my journey began. Please find any details about the underlying issue below.

Steps to reproduce the behavior:

1. Work on Windows
2. Create a folder with a pyproject.toml file
3. Create a subfolder and a file test.py in this subfolder
4. cd into the subfolder
5. Run Black on it by using the both commands given in the introduction
6. See the different output:
   • black --check -v test.py says Using configuration from <TESTFOLDER>\pyproject.toml.
   • type test.py | black --check -v - does not print any information about a config file being loaded

Expected behavior: Both commands should find and use the same configuration file, as the docs clearly describe, the current working directory is used as base for searching in case of reading from stdin.

Environment (please complete the following information):

• Version: 19.10b0 (and master)
• OS and Python version: Windows 10, Python 3.8.2

Does this bug also happen on master?: yes

Additional context

I researched the issue and found it being caused by a bug in Pythons pathlib library. As https://bugs.python.org/issue38671 is know for over 6 months and not resolved yet, black might want wo circumvent the issue by slightly changing the code.

The bug described here is caused as follows:

• black/src/black/__init__.py

  Line 5837 in 8d036ce

  path_srcs = [Path(src).resolve() for src in srcs]

  calls resolve() on all source paths
• as described in https://bugs.python.org/issue38671, resolve() actually does not make the path absolute (as stated in https://docs.python.org/3/library/pathlib.html#pathlib.Path.resolve) on Windows, if it does not exist. So Path('-').resolve() (the - coming from the input as symbol for reading from stdin) gets WindowsPath('-') (as opposed to Linux, where it gets PosixPath('<CWD>/-')).
• WindowsPath('-').parents just yields WindowsPath('.'), so the common_base calculated in the following lines is just WindowsPath('.') with empty common_base.parents.

Possible fixes:

• wait for Python to fix the bug in pathlib
• replace Path(src).resolve() in

  black/src/black/__init__.py

  Line 5837 in 8d036ce

  path_srcs = [Path(src).resolve() for src in srcs]

  by Path(Path.cwd() / src).resolve(). This should make sure, the path is really absolute under all circumstances