Skip to content

Conversation

@ruv
Copy link
Contributor

@ruv ruv commented Jan 30, 2025

If source-base-path (and then default-base-path) returns the path of a directory, this path shall end with the forward slash /. Because that's how the Base URI and Relative Resolution behave.

Currently, default-base-path returns a correct path only if the working directory is the root directory. Because only in this case getcwd returns a path ending with "/".

This is a quick and dirty fix. It adds the slash at the end if it is missing.

If `source-base-path` returns the path of a directory,
this path shall end with the forward slash `/`.
Because that's how the Base URI and Relative Resolution behave.
@SirWumpus
Copy link
Owner

Why not just ALWAYS append a / to the path? In file paths multiple slashes /// are treated as one and as I recall likewise URI. Its only humans who like it pretty.

@ruv
Copy link
Contributor Author

ruv commented Jan 30, 2025

Why not just ALWAYS append a / to the path?

If the working directory is the root directory, the resulting path will be "//", and this is an incorrect path in the File URI scheme.

When "foo/bar.fth" is straightforwardly resolved against "//", the resulting path is "//foo/bar.fth", which is a scheme-relative URI.

See also: https://url.spec.whatwg.org/#relative-url-string (the URL specification from WHATWG).

In file paths multiple slashes /// are treated as one and
as I recall likewise URI.

No, in the general case they are different URIs. Also, when several URIs are equivalent in some sense, I would prefer to have the URI in the normalized form.

@SirWumpus SirWumpus merged commit c3c9a3a into SirWumpus:master Jan 30, 2025
4 checks passed
@ruv ruv deleted the fix-default-base-path branch January 30, 2025 19:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants