[file/search] sound good, but would be confused with the (possibly useful functionality of "find", since to "find" with folder_list we would need to know the depth of directories to list [folder_list /*/*/*/*/*/.mov] etc..
[file/match] then seems to be a better fit...
Hans, did you make a wiki for each lib page? It would be good to document some of these ideas outside the list.
.b.
Hans-Christoph Steiner wrote:
On Apr 1, 2006, at 9:09 AM, B. Bogart wrote:
james tittle wrote:
On Mar 31, 2006, at 5:45 PM, Hans-Christoph Steiner wrote:
On Mar 31, 2006, at 11:42 AM, Frank Barknecht wrote:
Maybe [folder_glob] would be a better name? [folder_list] may lead users to expect a list - of whatever kind - as a result. (I would even prefer [folder_ls] but that my be too unixish.)
Yeah, [folder_list] is not the best name. ls and glob are too UNIXish, tho I love UNIX. Hmm.. [file/listing]? "list" really seems to be the common word here. [file_list] might be the best bet. Folders are usually considered files, while files are not considered folders ever..
...random ideas, to get away from using "list":
[folder_contents] [directory_search] [folder_directory] [directory] [folder_catalog] [directory_index] [folder_inventory]
james
folder_contents sounds damn clear!
Is directory stuff and file stuff in the same lib or two different ones?
[directory/contents]
[folder/contents]
[file/folder_contents]
There would be one library, "file". I think spliting them would make for a lot more work, and little gain. Most file operations also apply to folders, like date, time, name matching, permissions, etc.
I like the idea of searching, since it does patterns, and is not limited to one folder (i.e. /home/*/.tcshrc). Maybe:
[file/match] [file/search] [file/index]
And tho I am a UNIX geek, I think "folder" is the preferred term here. Its more widespread and I think it makes more sense than "directory" when you look at it from the interface level, rather than the implementation.
.hc
http://at.or.at/hans/