Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

pdir /b1 issue

May
603
0
*dir /b1 /s seems to work fine, but *pdir /b1 /s displays nothing.


TCC 13.00.15 Windows Vista [Version 6.0.6002]
TCC Build 15 Windows Vista Build 6002 Service Pack 2

--
Jim Cook
2011 Monday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.
 
From: Jim Cook
| *dir /b1 /s seems to work fine, but *pdir /b1 /s displays nothing.

Ah! I finally discovered how relative paths are displayed! I never looked under /B in options - esp. not for PDIR, where I would have expected something like "fr" instead of "fp", or "frn" instead of "fpn" to dislpay the relative paths IN THE SAME PLACE AND MANNER AS FULL PATHS! As is, I still need my @RELPATH function for PDIR if I want to see relative paths... No benefit from this new feature at all! And still much slower than need be due to calling a UDF for every line in the report, instead of an internal operation.
--
Steve
 
From: rconn
| There is no measurable speed difference between an internal function
| in PDIR and calling a [*] variable function.

Does this apply to user-defined functions? My function is defined thus:
relpath=%@quote[%@replace[%_cwds,,%@path[%@full[%&]]]]

Would this function execute as fast as "frq" would (where r would be the relative path determined internally), without calling any [*] variable function?
--
Steve
 
> Would this function execute as fast as "frq" would (where r would be
> the relative path determined internally), without calling any[*] variable
> function?

You *might* shave off a couple of microseconds. They all have to call the
same functions eventually.

I timed this extensively when creating PDIR, and there was never any
measurable (i.e., 1+ millisecond range) difference.
 
As a side note, /b is not listed in the command line help of pdir.

Code:
09:06:36 $ pdir /?
Display information about files and subdirectories in the specified format.

PDIR [/(...) /A[[:][-][+]rhsdaecjot] /D /H /I"text" /KM /N[dej] /O[[:][-]adeginorsu] /P /Sn /T[:
acw]] [file...]
        /(...) Fields to display
        /A(ttribute select)     /N[e] (no error)
        /D (colorize)           /O(rder)
        /H (display .. & .)     /P(ause)
        /I (match descriptions) /S(ubdirectories)
        /K (header)             /T date/time field
        /M (footer)
 
In the standard help file, I did nor see the description of the /() fields. Was I just blind?-- Sent from my HP TouchPadOn Sep 8, 2011 7:08, JohnQSmith <> wrote: As a side note, /b is not listed in the command line help of pdir.


Code:
---------
09:06:36 $ pdir /?
Display information about files and subdirectories in the specified format.

PDIR [/(...) /A[[:][-][+]rhsdaecjot] /D /H /I"text" /KM /N[dej] /O[[:][-]adeginorsu] /P /Sn /T[:
acw]] [file...]
/(...) Fields to display
/A(ttribute select) /N[e] (no error)
/D (colorize) /O(rder)
/H (display .. & .) /P(ause)
/I (match descriptions) /S(ubdirectories)
/K (header) /T date/time field
/M (footer)
---------
 
Ah! I finally discovered how relative paths are displayed! I never looked under /B in options - esp. not for PDIR, where I would have expected something like "fr" instead of "fp", or "frn" instead of "fpn" to dislpay the relative paths IN THE SAME PLACE AND MANNER AS FULL PATHS! As is, I still need my @RELPATH function for PDIR if I want to see relative paths... No benefit from this new feature at all!

You're a few months late for v13 feature requests / changes. Submit it in Feedback for the next major version.
 
WAD. Quick help does not include every option of every command.

Even if they are not described in the quick help, they should at least be enumerated in the summary line so as to show their existence.

If I saw a switch listed in the summary line that is not briefly described, my first instinct would be to check the help file. Without even showing the switch, I don't know it exists.

So instead of (as copied from the command line help)
Code:
PDIR [/(...) /A[[:][-][+]rhsdaecjot] /D /H /I"text" /KM /N[dej] 
/O[[:][-]adeginorsu] /P /S n /T[:acw]] [file...]
I would prefer to see (as copied from the help file)
Code:
PDIR [ranges] [/A:[attrlist] /B /D /H /I"text" /K /M /N[dej] 
/O:[order] /P /S[[+]n] /T:t /(...)] [file...]
maybe with a note at the end of the switch summaries mentioning checking the help file for information on the undefined switches.
 
From: rconn
| Originally Posted by Steve Fabian
|| Ah! I finally discovered how relative paths are displayed! I never
|| looked under /B in options - esp. not for PDIR, where I would have
|| expected something like "fr" instead of "fp", or "frn" instead of
|| "fpn" to dislpay the relative paths IN THE SAME PLACE AND MANNER AS
|| FULL PATHS! As is, I still need my @RELPATH function for PDIR if I
|| want to see relative paths... No benefit from this new feature at
|| all!
|
| You're a few months late for v13 feature requests / changes. Submit
| it in Feedback for the next major version.

It was the ONLY way I ever interpreted the request for relative paths in PDIR - instead, you added a new option switch to PDIR which disables all the /(...) reporting fields, without which PDIR is just an alternate name for DIR. Proof: in HELP topic PDIR the text for the /B option references the nonexistent /F option - obviously it is just a copy-and-paste version of the /B option of the DIR command.

The request for relative paths in PDIR was made in a timely manner for V13. Why should a request not implemented in V13 require resubmission for V14? Don't you keep a log of all requests?
--
Steve
 
> Even if they are not described in the quick help, they should at least
> be enumerated in the summary line so as to show their existence.

I tried that a few versions ago and got ten times as many complaints that
the option was in the summary but not in the details.

My preference is to eliminate quick help entirely, as it generates way too
many complaints for way to little return.
 
I must apologize for wording the original request badly. I now see why you
were so confused about the utility of the request.

I see now that what I requested could easily be interpreted as asking for
the /s /b1 that you implemented, it was not in fact what I meant to ask for.

I quote from the original request:

----quote----
If the current folder had two sub folders, one of which had its own
sub folder, a DIR /S would show:

file1
sub1\file2
subsub1\file3
sub2\file4

If I did DIR /S SUB1\* it would show

sub1\file2
sub1\subsub1\file3
----end quote----

And you implemented exactly that. However, I see now that I should not have
used a shorthand. DIR /S of course does not show only the filenames but
instead the date, time, size, and perhaps other information.\

What I should have said was this:

I would like to be able to change just the filename part of the PDIR (or
DIR) filename display to include relative paths. I want all the other
columns / fields that would otherwise be displayed to remain the same.
Currently, this is the output:

C:\Users\cookj\Temp>*dir /s /h /m /k
2011-09-08 09:31 <DIR> sub1
2011-09-08 09:33 <DIR> sub2
2011-09-08 09:30 271 file1
2011-09-08 09:32 <DIR> subsub1
2011-09-08 09:31 1,481 file2
2011-09-08 09:32 6,474 file3
2011-09-08 09:33 214 file4
C:\Users\cookj\Temp>*dir /s /h /m /k sub1
2011-09-08 09:32 <DIR> subsub1
2011-09-08 09:31 1,481 file2
2011-09-08 09:32 6,474 file3

And I would very much like this output instead. Note that the default sort,
grouped by directory, then filename (ignoring path), or any specified sort
should still respected.

C:\Users\cookj\Temp>*dir /s /h /m /k /(magicswitch)
2011-09-08 09:31:03 <DIR> sub1
2011-09-08 09:33:08 <DIR> sub2
2011-09-08 09:32:58 <DIR> sub1\subsub1
2011-09-08 09:30:55 271 file1
2011-09-08 09:31:03 1,481 sub1\file2
2011-09-08 09:32:58 6,474 sub1\subsub1\file3
2011-09-08 09:33:08 214 sub2\file4
C:\Users\cookj\Temp>*dir /s /h /m /k /(magicswitch) sub1
2011-09-08 09:32:58 <DIR> sub1\subsub1
2011-09-08 09:31:03 1,481 sub1\file2
2011-09-08 09:32:58 6,474 sub1\subsub1\file3

On Thu, Sep 8, 2011 at 09:15, rconn <> wrote:

>
> ---Quote---
> > It was the ONLY way I ever interpreted the request for relative paths in
> > PDIR
> ---End Quote---
> But your interpretation was (1) not the same as the original request, and
> (2) never shared.
>
> I don't keep a log of closed requests that somebody might have wanted to
> interpret differently! :-)
>
>
>
>



--
Jim Cook
2011 Monday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.
 
Sorry for just reposting part of his message, but I couldn't decipher it without wrapping his directory structures in
HTML:
 tags.
[quote="Jim Cook, post: 17360"]What I should have said was this:

I would like to be able to change just the filename part of the PDIR (or
DIR) filename display to include relative paths. I want all the other
columns / fields that would otherwise be displayed to remain the same.
Currently, this is the output:
[html]
C:\Users\cookj\Temp>*dir /s /h /m /k
2011-09-08  09:31         <DIR>    sub1
2011-09-08  09:33         <DIR>    sub2
2011-09-08  09:30             271  file1
2011-09-08  09:32         <DIR>    subsub1
2011-09-08  09:31           1,481  file2
2011-09-08  09:32           6,474  file3
2011-09-08  09:33             214  file4
C:\Users\cookj\Temp>*dir /s /h /m /k sub1
2011-09-08  09:32         <DIR>    subsub1
2011-09-08  09:31           1,481  file2
2011-09-08  09:32           6,474  file3
And I would very much like this output instead. Note that the default sort,
grouped by directory, then filename (ignoring path), or any specified sort
should still respected.
HTML:
C:\Users\cookj\Temp>*dir /s /h /m /k /(magicswitch)
2011-09-08 09:31:03       <DIR>   sub1
2011-09-08 09:33:08       <DIR>   sub2
2011-09-08 09:32:58       <DIR>   sub1\subsub1
2011-09-08 09:30:55           271 file1
2011-09-08 09:31:03         1,481 sub1\file2
2011-09-08 09:32:58         6,474 sub1\subsub1\file3
2011-09-08 09:33:08           214 sub2\file4
C:\Users\cookj\Temp>*dir /s /h /m /k /(magicswitch) sub1
2011-09-08 09:32:58       <DIR>   sub1\subsub1
2011-09-08 09:31:03         1,481 sub1\file2
2011-09-08 09:32:58         6,474 sub1\subsub1\file3
[/QUOTE]
 
My preference is to eliminate quick help entirely, as it generates way too many complaints for way to little return.

I'm certain that would generate far more complaints! Even CMD.EXE has quick help....
 
That might be better phrased as "CMD.EXE *only* has quick help ..."
Hardly. Pretty much any decent command line tool responds to a /? with a usage display, featuring details of the parameters and switches supported. Personally I would see nothing wrong with /? opening the standard help (there are plenty of existing examples of that approach) but I suspect that others might object to being pulled out of the console.
 

Similar threads

Back
Top