flist(".") behavior

ID:1628084
 
Jul 15 2014, 3:21 am
BYOND Version:506
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 35.0.1916.153
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
The format won't help much here, I think. This is more of a behavior issue:


flist("") //returns files in the current directory
flist("./") //returns files in the current directory
flist(".") //returns nothing



In both Linux and Windows file systems, . is the folder you are currently in.

Per the reference:
The path is of the form "dir1/dir2/.../file". Only files beginning with the "file" part are listed, so be sure to end a directory name with "/" if you wish to see its contents. Otherwise you will just get that directory name back with a "/" appended.

So, the behavior for "./" is correct. I guess the behavior for "" is something.

But, it seems (per the reference) like "." is supposed to return the name of the folder, and ".." would return the name of the folder above it.


I dunno if there's any way currently to find the name of the folder you're in, other than shell stuff, but this would be good, and the current behavior for "." and ".." seems contradictory to the reference. (or am I just assuming too much?)

not sure if bug, or feature request.
Jul 15 2014, 8:44 am
Indeed. Our notation choice is unusual here because it mostly matches shell notation but has the extra addition of the implied file/qualifier at the end. In shell notation, as far as I know there is no way to get the current directory through a file list command (you need to use pwd), so that part is consistent (albeit limiting). However, the documentation does seem to indicate that flist(".") and flist("..") should return "[cwd]/" and "[parent]/" respectively.

While this is an easy fix, I am concerned about the small chance it could break compatibility in games that use flist() to navigate down a directory tree (although off the top of my head, it's hard to see one doing this with the "buggy" notation). We'll decide if it's better to fix or to simply omit that last line from the notation. I do see the argument that a fix is useful since it would allow access to the cwd name, which is what you want.
Jul 17 2014, 5:18 am
There's that chance somebody uses flist(".") to generate a list of files beginning with a period.

Perhaps there could be some kind of alternate notation to get cwd and parent?
Jul 17 2014, 10:18 am
flist() won't return files beginning with . -- no file listing proc will, files beginning with '.' are considered hidden by both Windows and Linux systems. BYOND's file procs ignore hidden files.
Jul 17 2014, 10:36 am
In response to Nadrew
Nadrew wrote:
flist() won't return files beginning with . -- no file listing proc will, files beginning with '.' are considered hidden by both Windows and Linux systems. BYOND's file procs ignore hidden files.


But, it does return files beginning with ".", at least it does in Windows.

In Windows, files are not hidden unless their "hidden" checkbox is checked off in Properties (or toggle the hidden attribute some other way, like the command line) with is a property unrelated to the dot.
Jul 17 2014, 11:09 am
It ignores files beginning with . for me, regardless of being checked hidden, perhaps it's some OS-level setting somewhere. But regardless, if you have files beginning with . and they're not special files, you're doing something terribly wrong.
Jul 17 2014, 12:58 pm
Seems like flist also picks up desktop.ini (a hidden file), and the $RECYCLE.BIN folder, as well as a bunch of other hidden stuff from c:/, including pagefile.sys?
Jul 18 2014, 4:26 pm
In response to Nadrew
Nadrew wrote:
It ignores files beginning with . for me, regardless of being checked hidden, perhaps it's some OS-level setting somewhere. But regardless, if you have files beginning with . and they're not special files, you're doing something terribly wrong.

This is a property of windows explorer; you can have it set to hide file types. dotfiles are, to windows, merely nameless files with a ".whatever" extension (e.g. ".gitignore"). The windows APIs however do not do this.