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
Decide if .resolve
should work like POSIX realname
#5335
Comments
From @AlexDanielCode: Result: It does not resolve fully! Moreover, if we try something like Code: Result: Actually thrown at: Boom! |
From @smlsI works fine for me, provided that ../foo actually exists in the filesystem. If it doesn't, then `.resolve` leaves anything that comes after it in the path, unchanged: � say "sam/..".IO.resolve; � say "nonexistent/..".IO.resolve; I'm not sure if it would be theoretically safe for `.resolve` to handle a '..' that comes immediately after the first nonexistent folder name in the path, by simply popping that name off the stack. But note that POSIX doesn't do it either: $ realpath nonexistent/.. Then again, POSIX also doesn't allow '..' to backtrack over an existing non-directory file, whereas Perl 6's `.resolve` does: $ touch a.txt $ realpath a.txt/.. $ perl6 -e 'say "a.txt/..".IO.resolve' Do you want to keep this ticket open as an RFC? |
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanielOn Mon May 23 10:02:18 2016, smls75@gmail.com wrote:
You are right, I was wrong. However, there is a pull request here: rakudo/rakudo#775 Now, I'm not sure what this pull request does, but I'm pretty sure that the current error message is LTA (Unknown system error 2, huh?). That's not RFC at all though. So, maybe we should change the title a little bit? |
From @smlsI think this needs an explicit design decision first, that's why I suggested an RFC. Should `.resolve` ... a) ...be as strict as POSIX `realname`, i.e. expand the path from left to right, and abort with an error as soon as a nonexistent directory is encountered or when a file is treated like a directory? b) ...be as lenient as possible, i.e. return a partially-resolved path in case of non-existent parts, and allow `..` to follow an existing non-directory file, etc.? c) ...something in between? The comments in src/core/IO/Path.pm suggest that at least one aspect of the current behavior (returning partially-resolved paths), is intentional. This shouldn't be changed unilaterally by a patch "just because Bash does it". Someone more competent than me should sit down and think through the implications of the different possible `.resolve` behaviors, and come up with design that is deemed optimal for Perl 6 (and doesn't violate existing spec tests due to the Perl 6.c backwards compatibility guarantee). |
From @MasterDuke17Even if there are no other changes to existing behaviour, I would still Dan |
From @labsterOn Tue May 24 09:17:43 2016, smls75@gmail.com wrote:
When I originally speculated IO::Path.resolve, I think I was intending for it to return a usable filesystem path in all cases. Or more specifically: And I had another method, IO::Path.cleanup( parent => True ) which was intended to do logical path cleanup based only on the strings. That's still a real use case for me, though IO::Spec.canonpath( :$parent ) still exists to provide some more functionality there, even if I do need to create path objects after cleanup instead of before. So I think I vote for resolve to fail() on a path that tries to find the parent of a nonexistent directory. I can't think of a reason why this would be useful: So unless someone can come up with an actual use case for the line above, I suggest either: Note that there are few spectests running for IO::Path.resolve yet (there are 3 marked TODO), so I think we still have room to just consider this a plain rakudobug. |
From @zoffixznetThank you for the report. This issue is now resolved. If you wish .resolve to `fail` if it cannot completely resolve the path, set `:completely` named arg to True: https://docs.perl6.org/routine/resolve.html |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128214 (status was 'resolved')
Searchable as RT128214$
The text was updated successfully, but these errors were encountered: