-
Notifications
You must be signed in to change notification settings - Fork 23
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
joinPath("foo", "/bar")
should return "/bar"
#112
Comments
/cc @andreaferretti @dom96 would a PR to fix that be accepted? |
Sure, I guess. |
I think it's a terrible idea, but if everybody else does it this way... shrug Copy all files to # assume 'walkFiles' happens to return absolute paths:
for x in walkFiles("*.nim"):
# yay, '/' is smart and makes this either a nop or a failure
copyFile(x, "/backup" / x) |
just use copyFile(x, "/backup" / x)
=>
copyFile(x, "/backup" / x.relativePath("/")) where |
You know... I think we need |
Too late for v1 ;P |
This RFC is stale because it has been open for 1095 days with no activity. Contribute a fix or comment on the issue, or it will be closed in 7 days. |
Precedents are convincing enough, but I'd argue that the current beheviour seems logical: "Interpret Current implementation of |
Please take into consideration the security risk when changing the library: "htdocs" / "/etc/passwd" current version: after a surprise update that includes this proposal: Btw,
This has since been documented. |
Rejected, it's a terrible idea and an invitation for security breaches. |
joinPath("foo", "/bar")
should return "/bar"It's almost always the right thing to do. Eg:
Most languages I use do that, eg:
D, python, C#
For C++: as mentioned here (rust-lang/rust#16507 (comment)) The C++ committee has recently been dealing with this problem.
http://isocpp.org/files/papers/n4211.html issue 64
NOTE: the current buggy behavior is not documented (no example like
joinPath("foo", "/bar")
is provided) so that makes fixing it less problematic.The PR that fixes it should make sure overload
joinPath(parts: varargs[string])
is also fixed (with behavior: any absolute path found kills all the previous arguments) ; likewise with/
operatoroption B: if for some reason the breaking change is not acceptable, I suggest this: intoduce an optional third arg enum:
option C: another option is to go ahead with the proposed semantic change but when a flag
--transition=8268
is given, throw when 2nd arg is absBut I prefer to keep it simple and correct and follow the semantics of D, python, C#
The text was updated successfully, but these errors were encountered: