Add a `stat` DSL function about miller HOT 4 CLOSED

@Poshi please let me know if #1560 (merged to main) works for you

from miller.

So far, LGTM. But would it be too much work to get the whole stats struct?

struct stat {
    dev_t     st_dev;     /* ID of device containing file */
    ino_t     st_ino;     /* inode number */
    mode_t    st_mode;    /* protection */
    nlink_t   st_nlink;   /* number of hard links */
    uid_t     st_uid;     /* user ID of owner */
    gid_t     st_gid;     /* group ID of owner */
    dev_t     st_rdev;    /* device ID (if special file) */
    off_t     st_size;    /* total size, in bytes */
    blksize_t st_blksize; /* blocksize for file system I/O */
    blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
    time_t    st_atime;   /* time of last access */
    time_t    st_mtime;   /* time of last modification */
    time_t    st_ctime;   /* time of last status change */
};

With the inode number you can see if two files are the same.
With the number of hard links you can see if there are other pointers to this file.
With the owner and group IDs you can find the files that (does not) belong tom someone.
With the different times you can distinguish different events.
Also, not sure how to test for file existence. Call stat and check if error appear, maybe?
Distinguishing files from folders, soft links, hard links and fifos will be also welcomed.
On the other hand, the block size and the number of blocks are not relevant to me, but maybe other people find it relevant.

And going one step further from the stat call, following a soft link would be an extra point :-) But that is a completely different functionality, not just querying metadata, but the actual data of a softlink, which is the immediate destination of the softlink. And it can be followed a single step, or until the end of the potential soft links chain.

from miller.

:-O I took for given that the full stat call results would be forwarded to any language that was using it.
Well, at least we have FileMode in the structure. From there, the type of file can be derived (folder, regular, link, block...).
The other missing data would be useful, but just having what you already added will go a long way :-)
It is not worth looking into non-portable things, it would be a nightmare to develop, test and maintain. Better keep to the standard and portable data.
Thanks a lot!

from miller.

@Poshi that's the C stats struct :(

Go expose this os.FileInfo and I'm using it all:

• https://pkg.go.dev/os#File.Stat
• https://pkg.go.dev/io/fs#FileInfo

I can look into things that might vary per OS ...

from miller.