-
Notifications
You must be signed in to change notification settings - Fork 73
Improvements to the System library #1735
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
base: master
Are you sure you want to change the base?
Conversation
directory-contents returns a <file-locator> even for a symlink that resolves to a directory. Add a `resolve-links?` keyword to resolve links. This uncovered a bug in resolve-locator such that it would always return a locator of the same class that it was passed, regardless of the file system entity it resolved to.
This is fundamentally a file-system operation so it was a mistake to put it in the locators module in the first place. The "file" terminology matches that used in most other file-system exports. I've switched the way arguments are passed to the internal `%resolve-file` function here. The internal function only deals with strings, instead of locators. This avoids some unnecessary conversions when the user passes a string.
* Unix: Do not call expand-pathname from other file-system APIs. Username expansion should only be done explicitly by user code. * Unix: Fixed bug: expand-pathname("~") didn't work because "~" is turned into a file locator and %expand-pathname only handled directory locators. Same for "~user". * Windows: Rename %expand-pathname to %absolute-path (which is apparently what it was being used for) and re-implement %expand-pathname as a no-op. * Add a test. * Update documentation. Removed the method docs because they added no information over what the generic-function doc said.
* Also adds a release note for expand-pathname
The macros were written to save a few characters rather than for clarity and searchability (i.e. grep). The "used by" comments could easily get out of date so I removed them. I added type specs to each constant because it seems like it can't hurt.
Also added `follow-links?` keyword argument and a test. `$EINVAL` became unused and started causing a warning. I removed it from *-magic-numbers.dylan for all platforms without testing since it's not exported and all Unixen share the same implementation of link-target, which was the only place it was used. Fixes dylan-lang#1408
each directory is represented by a :class:`<directory-locator>`. The "." | ||
and ".." directories are not included in the result. | ||
Returns a sequence of locators describing the files contained in *directory*. The | ||
"." and ".." directories are not included in the result. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use the :file:
role for these
class of locator, :class:`<file-locator>` or :class:`<directory-locator>`, is | ||
determined based on the file type of the (fully resolved) link target. | ||
|
||
Note that if a symlink points to another file in *directory* then the resulting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use "symbolic link" consistently rather than the colloquial "symlink".
// expand-pathname generic function has a different purpose. See | ||
// https://github.com/dylan-lang/opendylan/issues/1728#issuecomment-3014101087 for my | ||
// reasoning for keeping this. | ||
define function %absolute-path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this should still be called %expand-pathname
, but it should be using GetLongPathName, per my comment on #1728.
Addresses some of the issues in #1728 and #1408