rconn wrote:
| Steve Fábián wrote:
|
|
| ---Quote---
|| 1/ When DIR or PDIR reports subdirectory count, exclude the . and ..
|| pseudosubdirectories IF the /H option is present in DIR, or absent
|| in PDIR, in other words, if they would not be displayed in the
|| subdirectory list.
| ---End Quote---
| Not sure what you're asking for here -- DIR already excludes the . and
| .. directories if you use /H, and PDIR never displays a subdirectory
| count.
Sorry, testing 9.02.151 again showed that it already reports in the manner I
asked. BTW, for PDIR I meant "when using /M option" to force reporting of
file and directory counts.
| ---Quote---
|| 2/ Provide the equivalent of the DIR /U option in PDIR, with
|| user-definable output format
| ---End Quote---
| I'll add it to the suggestion list, but IMO that's warping PDIR beyond
| its intent. (Especially since it can be easily done with existing
| variable functions.)
OK.
| ---Quote---
|| 3/ In PDIR output format allow the user to define a field
|| specification separator. This separator would not appear in the
|| output, but would allow the user to request that the output fields
|| whose specification it separates would be adjacent
| ---End Quote---
| I have no idea what you're asking for here ...
Suppose I want the filedate and filetime reported as a single string,
without separator. This cannot now be done. For the sake of argument, let's
say I have somehow specified that in the output format definition the #
character is to act as a separator. Now the command below
*pdir/(dymd#thms fn) *.txt
would display
20080517100505 a.txt
20080502092408 addrbook.TXT
20080228112041 DIR.TXT
and the command below
*pdir/(dy.m.d#.#t.h.m.s fn) *.txt
would display
2008.05.17.10.05.05 a.txt
2008.05.02.09.24.08 addrbook.TXT
2008.02.28.11.20.41 DIR.TXT
| ---Quote---
|| 4/ In PDIR output format allow the user to request narrower than
|| default width for fields, esp. for file size, with a "caveat emptor"
|| warning in the documentation.
| ---End Quote---
| I have two problems with that -- nobody reads the documentation before
| they report a "bug"; and nobody reads the documentation before they
| report a "bug" ...
I agree with the existence of the problem - my first suggestion in this list
was asking for an existing feature. However, in this case, if you go back to
the messages you received at the time the file size field was widened to 15
columns, most users were expecting that the width specification available
for other fields:
"You can also specify a format, independently for each field, by prefixing
the field character with its format specification:
[-]i.a"
should also apply to the file size "z" field. So I am just suggesting that
the current wording
of the help topic "pdir.htm" be fully implemented. In fact, it would AVOID
reporting WAD as a
bug.
| As a rule, I'm very reluctant to add "features" that are guaranteed to
| be misused and generate support incidents. Why do you think this
| would be beneficial?
PDIR is often used to create "tabulated" output. When you know that a given
execution of PDIR will never find filesizes wider than (e.g.) 5 digits, my
suggestion allows making the output narrower. This is esp. true when one of
the magnitude prefixes is used, when current reporting still uses 15
columns, even if you report sizes in terabytes.
--
Steve
