the man page, in particular, in one of the EXAMPLES it is claimed:
This example produces output very similar to that from find ... -ls
(except that find(1) displays the time in a different format, and find(1)
sometimes adds one or more spaces after the comma in “major,minor” for
device nodes):
and then uses %9Z in the format, but conveniently does not use a
device file to demonstrate.
If it had, the result would have been:
8033 0 brw-r----- 1 root operator 4, 51 Jun 8 02:44:45 2022 /dev/sd3
Note the spaces which were claimed to exist (sometimes) in find(1) output
but not with stat. Oops.
Omitting those spaces seems like a good idea, so does using the same
field width for the result in both cases, rather than producing 9 chars
in the ordinary file case, and 19 (2 * 9 + 1) in the device case (for %9Z).
Now we will get:
8033 0 brw-r----- 1 root operator 4,51 Jun 8 02:44:45 2022 /dev/sd3
While here, also make the file number (%@) when reading stdin be 0, it is
not the 1st file in the arg list.
Some (very minor) KNF applied at the same time.
In stat.1 make these changes explicit.
Apologies to cvs commit purists, but making this division required
line by line reading of the man pages, and I simply could not resist
also correcting some errors, addressing some omissions, improving some
wording ... all at the same time.
correctly, in particular %%f does not contain the %f format, and like
all strftime conversions, %f can occur more than once (not that it is
likely to happen, but just in case...)
so it only applies to -x (in particular, not to -s) and only if another
time format has not been explicitly selected (earlier in the arg list).
With luck, this will make lots of tests, which depended upon "stat -s"
actually generating correct sh assignment statements, go back to working again.
in the format string) so that we can "or" it with the bits in the
formats variable. This fixes the missing " -> " in front of the real
path (when you use %SR).
Also, the ?: needs another space.
wiz