Re: RFE: stat(1) flag for learning the d_type value of a given file

[Pádraig Brady]

On 10/13/2014 09:34 PM, Eric Blake wrote:
> On 10/13/2014 02:14 PM, Pádraig Brady wrote:
>> On 10/13/2014 08:56 PM, Eric Blake wrote:
>>> The Cygwin developers have been trying to improve some d_type hints
>>> given during readdir(), to return DT_DIR instead of DT_UNKNOWN for
>>> obvious directories, as an example.  But testing the patches for
>>> correctness has proved to be a bit of a challenge for testing.  On an
>>> IRC chat, we discovered that it is really difficult to find out what
>>> d_type lists for a given file without using a debugger or writing a
>>> custom program - most GNU code is using it as an optimization to avoid
>>> lstat(), but never directly outputs that the optimization took place.
>>> So the idea was raised: could we teach stat(1) a new format arg that
>>> would make it painfully obvious what d_type hint is associated with a
>>> given file?
>>>
>>> Of course, such a format is not trivial, and must not be part of the
>>> default stat output.  Given 'stat --format=... a', you'd have to do
>>> readdir() on "." until you find "a", in order to get to the d_type.  But
>>> I couldn't think of any better utility to enhance to easily get at
>>> d_type information from the shell.  At least, stat(1) feels like a
>>> better choice than ls(1) for adding the enhanced output information.
>>>
>>> What do you think? Should I spend time writing up a patch?
>>
>> Maybe, though coreutils' tests also check d_type is available.
>> Would this suffice for cygwin?
>>
>> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=tests/d_type-check;hb=HEAD
> 
> That seems like a useful starting point for a hack, but it's a bit too
> platform-specific (libc = ctypes.cdll.LoadLibrary("libc.so.6") has no
> chance on Cygwin, and even hardcoding the assumption that DT_DIR==4 is a
> bit risky, although it works for Cygwin).  The fact that it takes that
> much effort in python is making me like the idea of a stat format
> modifier even more, especially since d_type exists on multiple platforms.

I was thinking a bit about the interface in stat(1),
but nothing really fits. We could have a separate mode
like we do for file system info, though it wouldn't be worth it
since d_type is the only thing you'd really want output from a dirent.
You could have %E to output the dirEnt->d_type,
though it just doesn't just fit nicely with stat(1).

I wonder would it be a better fit with find(1)?

  $ find . -maxdepth 0 -printf '%Et\n'
  d
  $ find /proc -maxdepth 0 -printf '%Et\n'
  U

d_type_supported() { test $(find . -maxdepth 0 -printf '%Et') = 'd'; }

Pádraig.