Missing PDir option...

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
This is not a really a big deal given that it's easy enough to write a user-defined function to provide this information, but shouldn't PDir have a field code that is the opposite of the "/NL" (No-Link") option on the "Dir" command; i.e. something that means "Link"? (If it has one already please forgive me; I can't find it but then I have poor eyesight...)
 
#2
mathewsdw:
| This is not a really a big deal given that it's easy enough to write
| a user-defined function to provide this information, but shouldn't
| PDir have a field code that is the opposite of the "/NL" (No-Link")
| option on the "Dir" command; i.e. something that means "Link"? (If it
| has one already please forgive me; I can't find it but then I have
| poor eyesight.)

The PDIR command, when using NO options, does report the target of junctions. (I run WinXP, which has only junctions, not symlinks). If you explicitly enumerate the reporting fields, you can include @junction[*] or @symlink[*] as a reporting field. The function you requested is thus already a built-in.

I had requested that - similar to field code R being equivalent to specifying @CRC32 - field codes be made available to represent the @INODE and @LINKS functions, but Rex rejected it with the comment (IIRC) they are not used frequently enough.
--
Steve
 
#3
The PDIR command, when using NO options, does report the target of junctions. (I run WinXP, which has only junctions, not symlinks). If you explicitly enumerate the reporting fields, you can include @junction
[*] or @symlink
[*] as a reporting field. The function you requested is thus already a built-in.

I had requested that - similar to field code R being equivalent to specifying @CRC32 - field codes be made available to represent the @INODE and @LINKS functions, but Rex rejected it with the comment (IIRC) they are not used frequently enough.
--
Steve
Thank you for your response, Steve, but I am aware that those two functions exist, the problem is that it is two functions!!! And the function that I wrote that I referred to in my original request does nothing more than combine the outputs of the @Junction and @SymLink functions in an @If function; I do not care whether it is a junction or symbolic link; I only care that it is linked and where-to (just like in the "dir" and "pdir" commands with no field-code options); and again, this not a real big deal, just a minor (and rather silly in my eyes) irritation...
 
#4
---- Original Message ----
From: mathewsdw
| Quote:
| Originally Posted by Steve Fabian
| The PDIR command, when using NO options, does report the target of
| junctions. (I run WinXP, which has only junctions, not symlinks). If
| you explicitly enumerate the reporting fields, you can include
| @junction[*] or @symlink[*] as a reporting field. The function you
| requested is thus already a built-in.

Thank you for your response, Steve, but I am aware that those two functions exist, the problem is that it is two functions!!! And the function that I wrote that I referred to in my original request does nothing more than combine the outputs of the @Junction and @SymLink functions in an @If function; I do not care whether it is a junction or symbolic link; I only care that it is linked and where-to (just like in the "dir" and "pdir" commands with no field-code options); and again, this not a real big deal, just a minor (and rather silly in my eyes) irritation...
---- End of Original Message ----

I fully agree with your frustration. I don't (yet) have access to TCC on Vista or 7, thus I have not tested %@junction[symbolic_link], but assuming that it is analogous to @symlink behavior (i.e., if @junction's parameter is anything else than a junction, the function value is an empty string), you could simply create a UDF (see linked_to below) whose value is the concatenation of these two functions, without the need to use @if. I presume this is functionally equivalent to the UDF you created. Alternately, you can just use the @truename function, but beware of its use on a mapped network drive.

function linked_to=`%@symlink[%1]%@junction[%1]`

BTW, please do not quote the signature line - when posts are replied to by email, the email client truncates the response at the signature mark. I had to copy your response manually.
--
Steve
 
#5
I fully agree with your frustration. I don't (yet) have access to TCC on Vista or 7, thus I have not tested %@junction[symbolic_link], but assuming that it is analogous to @symlink behavior (i.e., if @junction's parameter is anything else than a junction, the function value is an empty string), you could simply create a UDF (see linked_to below) whose value is the concatenation of these two functions, without the need to use @if. I presume this is functionally equivalent to the UDF you created. Alternately, you can just use the @truename function, but beware of its use on a mapped network drive.

--- Dan

function linked_to=`%@symlink[%1]%@junction[%1]`

BTW, please do not quote the signature line - when posts are replied to by email, the email client truncates the response at the signature mark. I had to copy your response manually.
--
Steve
Your are, of course, correct. However, the function I wrote outputs a string of dashes ("-------------------") when the given directory is not a junction or symbolic link which makes it a bit more than a simple concatenation of @SymLink @Junction, but, as you can probably tell, I was completely willing to give that up, and would have been useful in the UDF that I did write! And I must admit I completely forgot about the "@TrueName" function, which is a very good idea, and since this is strictly a "home" computer and therefore does not have any access to "network drives", that's not an issue.

And I'm sorry, but I really don't understand your comment about "quoting the signature line", and I hope I'm not doing it again here! Please further explain so I can avoid doing that to you (or other people) again...

--- Dan
 
#6
And I'm sorry, but I really don't understand your comment about "quoting the signature line"
Signature lines are where you sign your message. In your case it would be and in Steve's it's When quoting, try to quote only the pertinent portion of the message. It also enhances understanding.