Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior on trailing slash #78

Open
TheDaemoness opened this issue Mar 8, 2022 · 1 comment
Open

Unexpected behavior on trailing slash #78

TheDaemoness opened this issue Mar 8, 2022 · 1 comment
Labels

Comments

@TheDaemoness
Copy link

My intuition is that paths with trailing slashes should be treated the same as paths without them. I've written my EditorConfig core in Rust (which, at the time of writing, passes the full core test suite) to have this behavior.

This does not match EditorConfig Core C's behavior.

$ cat .editorconfig
root = true

[foo]
matched=true
$ editorconfig --version
EditorConfig C Core Version 0.12.5
$ editorconfig $PWD/foo
matched=true
$ editorconfig $PWD/foo/
$ ec4rs-parse $PWD/foo
matched=true
$ ec4rs-parse $PWD/foo/
matched=true
@cxw42
Copy link
Member

cxw42 commented Mar 12, 2022

That is an interesting one. I recall that the C core assumes its inputs are fully canonicalized, which I don't think $PWD/foo/ is. I can't find a clear statement on the subject, but I did find some data:

  • POSIX 2004 A.4.11 "requires that a pathname with a trailing slash character be treated as if it had a trailing /. everywhere." Since canonicalization strips /. components, that would imply to me that trailing / was not canonical.
  • POSIX 2017 4.13 says that, for symlink resolution, resolution is not complete if the pathname has a trailing slash.

@cxw42 cxw42 added the question label Mar 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants