V10 suggestions

#1
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.

2/ Provide the equivalent of the DIR /U option in PDIR, with user-definable
output format

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

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.
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,533
94
#2
Steve Fábián wrote:

> 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.
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.


> 2/ Provide the equivalent of the DIR /U option in PDIR, with user-definable
> output format
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.)


> 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
I have no idea what you're asking for here ...


> 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.
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" ...

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?

Rex Conn
JP Software
 
#3
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