Skip to content

fs::list_dir should only return the contents of the directory #1919

Closed
@jsternberg

Description

@jsternberg
Contributor

Currently using fs::list_dir will append the directory name to the front of every entry. I think fs::list_dir should only return the contents of the directory, and maybe another utility function should use fs::list_dir to give the current behavior.

The only other way I can see to access the contents of a directory is with os_fs::list_dir, but that seems like it's not supposed to be public. A comment in the source code has:

// FIXME: generic_os and os_fs shouldn't be exported
export generic_os, os, os_fs;

Activity

ghost assigned on Mar 8, 2012
catamorphism

catamorphism commented on Mar 8, 2012

@catamorphism
Contributor

I'm not sure how to determine what the correct behavior is. Is fs::list_dir supposed to implement some standard Unix API? I'm assuming it works the way it does for a reason.

Assigning to @brson since he seems to have touched this code.

jsternberg

jsternberg commented on Mar 9, 2012

@jsternberg
ContributorAuthor

The main issue is that there doesn't seem to be an easy way to get a directory listing without accidentally prepending the current directory to every entry returned. So currently, if I want to find the entries in a directory, I need to use fs::list_dir then slice off the section of the string dealing with the current directory. It's much easier to join two paths than it is to remove a path.

If I don't want to go about modifying the string that many times (fs::list_dir goes out of its way to prepend the directory name), my only current choice is to start messing around with opendir and readdir in native code. To do something as simple as listing a directory, I really shouldn't have to start messing around with pointers and unsafe code.

brson

brson commented on Mar 9, 2012

@brson
Contributor

I do appear to have touched this code as I wrote the only bit of code that actually uses it. I don't remember why it behaves the way it does - probably because that is the exact functionality that rustc needed at the time - but let's change it to do the more intuitive thing. @jsternberg are you interested in making the change?

brson

brson commented on Mar 9, 2012

@brson
Contributor

Oh, cargo uses it more than rustc, so clearly there's a good use case for the current behavior. Maybe we should split it into two functions, or at least make sure there's an easy one-liner to get the current behavior.

jsternberg

jsternberg commented on Mar 9, 2012

@jsternberg
ContributorAuthor

Yea, I can make the change at some point this weekend. If cargo is the only thing that uses it, I'll change that too.

brson

brson commented on Apr 1, 2012

@brson
Contributor

Fixed by 3a0477c. Thanks @jsternberg

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @brson@catamorphism@jsternberg

      Issue actions

        fs::list_dir should only return the contents of the directory · Issue #1919 · rust-lang/rust