file/directory functions

[HarlanH]

Julia needs at least some of the usual file/directory manipulation functions. Something like stat, for sure, as well as readdir, maybe glob.

Also, this is a bug:

julia> is_file_readable(".")
true

[raggi]

stat and glob have structures. stat particularly varies by OS, so it's hard to completely cover this abstraction purely with dl* and hacks to map the internal structure to well defined types.

Do we want to wait for that clang header stuff before doing this, or add some C code to handle these cases? I too found myself wanting a stat(2) interface.

[JeffBezanson]

There are a bunch of functions in file.jl and stat.jl. Some of the file functions should probably be changed to use stat, and duplicates should be removed. @johnmyleswhite why does download_file involve renaming to .tar.gz? That doesn't seem quite sane.

[johnmyleswhite]

It's not sane. That's a complete mistake. I just copied those definitions straight from the code I had used to hack up a system to download a "package" from GitHub; the files sometimes lost that extension during the process, so it would add the extension back manually.

[JeffBezanson]

I have another complaint: there should be a more consistent naming scheme. For example we have both split_path and path_rename. The names should either be highly standard (e.g. POSIX) like realpath or follow noun_verb.

[StefanKarpinski]

Hmm. This may be true, but we generally follow English readability order in Julia naming...

[johnmyleswhite]

The names I added (e.g. path_expand) came from R. I don't particularly like them and would be very happy to see them replaced with names that are closer to English word order.

-- John

On Aug 2, 2012, at 10:44 AM, Stefan Karpinski wrote:

Hmm. This may be true, but we generally follow English readability order in Julia naming...

---

Reply to this email directly or view it on GitHub:
#560 (comment)

[JeffBezanson]

Naming involves several factors. Most of the names we have now are reasonably standard in one way or another, and our multi-word names generally do not form "families" of functions. For example countlines does not imply a family of count or line functions. But, there are several path-specific functions so it seems to make sense for them to share a prefix. This is also a rare case where generic names can't be used, since many functions are just string functions, and something like expand(str) can't be path-specific.

[vtjnash]

i think we have this now. it's probably better to open new issues for specific requests (such as glob).