Skip to content
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

Plan for iolib/pathnames and file system functions? #63

Open
Ambrevar opened this issue Jun 8, 2021 · 3 comments
Open

Plan for iolib/pathnames and file system functions? #63

Ambrevar opened this issue Jun 8, 2021 · 3 comments

Comments

@Ambrevar
Copy link

Ambrevar commented Jun 8, 2021

cl:pathname are notoriously difficult to use among others because of how their automatically parse wildcards.

See https://old.reddit.com/r/Common_Lisp/comments/nsqrcb/wildcardless_alternative_to_clpathname/ for a discussion.

It would be nice to offer a wildcard-less alternative to the CL community. iolib/pathnames and the iolib/os file system helpers seem to achieve just that :)

But I can't find much documentation about these parts of iolib.
What's their ultimate goal, provide a full blown replacement for the cl:pathname API?
If so, a few more helpers and features would be welcome, like the ones from https://shinmera.github.io/pathname-utils/. I would be happy to contribute if this fits the project goals.

Last, the CL community does not seem to be largely aware of the existence of iolib/pathname: maybe we could proselytize a little, like on awesome-cl, etc.?

@sionescu
Copy link
Owner

sionescu commented Jun 8, 2021

Yes, the goal is to provide a complete replacement for CL pathnames and file-system operations.
I looked at the API of pathname-utils but it's not clear to me what you think that IOlib is missing, since all those functions depend on the CL semantics such as a distinction between files and directories, embedding the host in the pathname, wildcards, etc...

As for advertising IOlib, the problem is that the necessary dependency in libfixposix makes it unpalatable for many, in addition to the fact that effectively it doesn't work in Windows (the code is written with Unix/Windows support in mind but I don't use Windows and am not interested in working in Windows support).

@Ambrevar
Copy link
Author

Ambrevar commented Jun 9, 2021

With pathname-utils I just meant to provide an example of convenient helpers, of course many don't apply here.

Some helpers that I have in mind:

  • (relative-p FILE MAYBE-PARENT)
  • (depth FILE MAYBE-PARENT: return the depth of FILE with regard to MAYBE-PARENT.
  • parent: return the parent path.
  • basename: return the name of the path (extension included).
  • (subdirectory root &rest subdirs)
  • make-directory
  • with-open-file alternative
  • delete-file

I'd be happy to contribute some if you like this list :)

About libfixposix: Do you think it's always needed for file system operations?
Maybe we could have compiler specific code (e.g. SBCL has sb-posix:readlink), only to fall back on libfixposix if the user compiler does not support the required file system operation. This way we could have a libfixposix-less system at least for some compilers.

I can't help with Windows support either, but if we start advertizing it, someone else might chime in. I'm guessing from the Reddit discussion that too few people are aware this library exists at all :p

@Ambrevar
Copy link
Author

Ambrevar commented Jun 9, 2021 via email

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

No branches or pull requests

2 participants