Skip to content

join() not working as advertised #546

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

Closed
rohintoncollins opened this issue May 16, 2024 · 1 comment · Fixed by #873
Closed

join() not working as advertised #546

rohintoncollins opened this issue May 16, 2024 · 1 comment · Fixed by #873
Assignees

Comments

@rohintoncollins
Copy link

rohintoncollins commented May 16, 2024

pubspec.yaml:

  path: ^1.9.0
join('/ZCLOUD', 'ZCloud Master Key :grinning:§ąśćżłóę:.txtÆ.txt')

should return

/ZCLOUD/ZCloud Master Key :grinning:§ąśćżłóę:.txtÆ.txt

It is incorrectly returning

ZCloud Master Key :grinning:§ąśćżłóę:.txtÆ.txt

Of note is the emoji 'colon-grinning-colon'
plus the other special characters '§ąśćżłóę'
plus a colon which is a forward slash in the macOS Finder file name (and is represented by a colon)
plus the 'Æ' character.

@mosuem mosuem transferred this issue from dart-archive/path Oct 17, 2024
@lrhn
Copy link
Member

lrhn commented Mar 21, 2025

Appears to be the behavior of the URL-style, not Posix or Windows.

The URL style most likely considers the second string to be a URI with a scheme, so not a relative path at all, which makes it discard the prior path.
If you check Context(style:Style.url).isAbsolute(...) of the "ZCloud Master...." string, it says true, unlike the other styles.

From the documentation of join:

/// If a part is an absolute path, then anything before that will be ignored:
///
///     p.join('path', '/to', 'foo'); // -> '/to/foo'

Since the second path segment there, using the URL strategy in the context, is absolute, the behavior is correct.

We should consider whether we should improve the isAbsolute for the URL strategy to only recognize actual valid schemes (of the form [a-zA-Z][a-zA-Z0-9+\-.]*:), rather than anything containing a : before a /.

(I'll see if I can make the URI parsing more precise.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants