# \[ENH\] Paths handling

**URL:** https://discourse.cmake.org/t/enh-paths-handling/1313
**Category:** Development
**Created:** [June 3, 2020, 2:59pm UTC](https://discourse.cmake.org/t/enh-paths-handling/1313 "2020-06-03T14:59:56Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![marc.chevrier](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/ecb155/32.png) [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [June 3, 2020, 2:59pm UTC](https://discourse.cmake.org/t/enh-paths-handling/1313/1 "2020-06-03T14:59:56Z")

</div>

Currently the handing of filesystem paths is not quite optimal:

- Handling is dispatched on two commands: `get_filename_component` and `file`
- `get_filename_component` is a bit counterintuitive because it is used for operations other than extracting component from filename
- Some basic capabilities are not available (see [#19568](https://gitlab.kitware.com/cmake/cmake/-/issues/19568))

Moreover, it is not clear which operations require filesystem access or not. And even more curious, `get_filename_component` can be used to read the Windows registry (not documented).

So, I propose to introduce the new command `cmake_path` to manage all operations on path not requiring filesystem access (same semantic as `std::filesystem::path` C++ class) and use `file` command for operations requiring filesystem access (so `get_filename_component(REALPATH)` should be offered as part of `file`).

For the command name, `path` should be nice, but I am afraid that it is no longer possible to introduce a such name without creating conflicts with existing user’s code. And, anyway, the goal is not handle paths in `CMake` format…

For the possible operations of `cmake_path`, I propose to follow what is offered by `std::filesystem::path` with a `CMake` twist of course 🙂

And for Windows registry access, may be a dedicated command should be fine. Or a module relying on `reg` windows command should be fine as well.

@brad.king, @craig.scott, @kyle.edwards Comments welcome.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [June 4, 2020, 11:31pm UTC](https://discourse.cmake.org/t/enh-paths-handling/1313/2 "2020-06-04T23:31:00Z")

</div>

Cc: @ben.boeckel

It would be great to clean up and formalize filesystem operations both internally and in the CMake language. However, the old path “translation map” may get in the way and should probably be handled first. See [CMake Issue 16228](https://gitlab.kitware.com/cmake/cmake/-/issues/16228).