Batch file to show Network drives

[Herb Martin]

Nod, I thought of the same thing re: the letter-depth but figured it's
so nigh-on moot for the same reasons ...

That's why I did like the pipe to find "\".

Here's the current one that doesn't mess up with "Drives:"
on XP (I hadn't notice the error until Esra pointed that
out (I was testing under 2003 mostly and who would have
thought that XP and 2003 which both WORK basicly
would be different in a new way?)

[Following is all one line for a batch file]

@for /f %%a in ('fsutil fsinfo drives ^| find "\"') do @if not
"%%a"=="Drives:" fsutil fsinfo drivetype %%a


I didn't use "For" option SKIP=1 because it would be different
for XP vs. 2003.

Sure that skips the text "Drives:" but it doesn't pick up my floppy drive
letter

Harlan's works best (likely even for that A and it is pretty much the
simplest (not QUITE elegant but it beats mine) and uses no weird
tricks, external utilities, nor temp files.

It works as is on (at least) XP, 2003, and Vista:

[All one line for batch file:]
@(for %%d in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
@fsutil fsinfo drivetype %%d | @find "No such " /v

 

[Dean Wells \(MVP\)]

Sadly, that too seems to fail on Vista.

Herb, I may be missing something here but the later version of my
original syntax works across the board and, as I mentioned earlier,
iterates through only those drive assignments that already exist. Are
you adverse to that particular syntax? Perhaps because it uses a TEMP
file per your earlier 'best-practices'?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

...

The following seems to work under XP. Also all one command line.

(for %d in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do ^
@fsutil fsinfo drivetype %d | find "No such " /v

My experience is that it is much slower to check invalid
drive letters than to just check those that (FSUtil says) exist,
but that doesn't seem to be the case with this command you
offer.

It works on (at least) XP, 2003, and Vista so I think yours is
the best I have seen so far, and I am sorry I didn't try going
right at all the drives to start with. <GRIN>

I guess it turns out that the "Fsutil fsinfo drives" is just a waste
of
time and effort (programmer and computer).


Thanks

 

[Dean Wells \(MVP\)]

Correct, a mis-paste on my part; that does work on Vista.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

Sadly, that too seems to fail on Vista.

Herb, I may be missing something here but the later version of my
original syntax works across the board and, as I mentioned earlier,
iterates through only those drive assignments that already exist. Are
you adverse to that particular syntax? Perhaps because it uses a TEMP
file per your earlier 'best-practices'?

 

[Dean Wells \(MVP\)]

Nod, I thought of the same thing re: the letter-depth but figured
it's so nigh-on moot for the same reasons ...

That's why I did like the pipe to find "\".

Here's the current one that doesn't mess up with "Drives:"
on XP (I hadn't notice the error until Esra pointed that
out (I was testing under 2003 mostly and who would have
thought that XP and 2003 which both WORK basicly
would be different in a new way?)

[Following is all one line for a batch file]

@for /f %%a in ('fsutil fsinfo drives ^| find "\"') do @if not
"%%a"=="Drives:" fsutil fsinfo drivetype %%a


I didn't use "For" option SKIP=1 because it would be different
for XP vs. 2003.

Sure that skips the text "Drives:" but it doesn't pick up my floppy
drive letter

Harlan's works best (likely even for that A and it is pretty much
the
simplest (not QUITE elegant but it beats mine) and uses no weird
tricks, external utilities, nor temp files.

It works as is on (at least) XP, 2003, and Vista:

[All one line for batch file:]
@(for %%d in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
@fsutil fsinfo drivetype %%d | @find "No such " /v

Hehe ... if I didn't exploit the specific behaviors that go beyond a
command's original purpose ('trick' seems so negative), I'd unacceptably
limit the scope of what a batch file can do for me. Take this simple
example -- the ability to echo out text and hold the cursor at the end
of the line rather than be subject to the implicit CRLF ... that's an
odd use of a set statement for sure but is commonplace because it's
necessary. Keeping some of the best-practices you mentioned in mind, my
feeling is that the unbelievably severe limitations of this aging shell
we seem to sooo love make it necessary to exploit any and all
predictable/consistent behaviors.

I agree entirely on using only core binaries unless absolutely no other
solution exists but I'm only adverse to the use of TEMP files to the
point of it not compromising the script's ability to do what it does in
the best way possible. My avoidance of TEMP files is motivated only by
the need to clean them up and the additional code required to do so;
nothing more. Let's face it -- when was the last time a problem
occurred because of a TEMP file that wasn't attributed to poor syntax (I
can't recollect even one) -- if the creation of the TEMP file failed for
any other reason, the effect on the script is probably a much lesser
concern than its root cause.

In this particular case, my feeling is that avoiding the use of TEMP
files at the expense of checking types for drive assignments that don't
even exist is, to my mind, an example of such a compromise ... but
that's just me and, of course, I like my syntax better :0)

 

[Dean Wells \(MVP\)]

Sheesh ... that's 'sposed to say 'correction' ... man, this could go on
forever ...

<double-checking> ...
<checking again> ...
<submit>

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

Correct, a mis-paste on my part; that does work on Vista.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

Sadly, that too seems to fail on Vista.

Herb, I may be missing something here but the later version of my
original syntax works across the board and, as I mentioned earlier,
iterates through only those drive assignments that already exist.
Are you adverse to that particular syntax? Perhaps because it uses a
TEMP file per your earlier 'best-practices'?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

The following works on 2003 and Vista but is really slow (at least
on 2003) when it encounters a disconnected network drive letter
that *IS*
mapped:

ALL ONE LINE FOLLOWING:

for %%a in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
@if
exist %%a:\lpt1 @fsutil fsinfo drivetype %%a:
...

The following seems to work under XP. Also all one command line.

(for %d in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
^
@fsutil fsinfo drivetype %d | find "No such " /v

My experience is that it is much slower to check invalid
drive letters than to just check those that (FSUtil says) exist,
but that doesn't seem to be the case with this command you
offer.

It works on (at least) XP, 2003, and Vista so I think yours is
the best I have seen so far, and I am sorry I didn't try going
right at all the drives to start with. <GRIN>

I guess it turns out that the "Fsutil fsinfo drives" is just a waste
of
time and effort (programmer and computer).


Thanks


This produces the following results, not including the lines of
dashes.

------
B: - Remote/Network Drive
C: - Fixed Drive
D: - Fixed Drive
F: - Remote/Network Drive
G: - CD-ROM Drive
H: - Remote/Network Drive
I: - Remote/Network Drive
J: - Remote/Network Drive
K: - Remote/Network Drive
L: - Remote/Network Drive
M: - Remote/Network Drive
P: - Remote/Network Drive
S: - Remote/Network Drive
T: - Remote/Network Drive
U: - Remote/Network Drive
V: - Remote/Network Drive
W: - Remote/Network Drive
X: - Remote/Network Drive

 

[Harlan Grove]

I agree entirely on using only core binaries unless absolutely no other
solution exists but I'm only adverse to the use of TEMP files to the
point of it not compromising the script's ability to do what it does in
the best way possible. My avoidance of TEMP files is motivated only by
the need to clean them up and the additional code required to do so;

....

Raises a few questions.

1. May cscript now be considered a core utility?
2. How about scripted use of debug?
3. Does a vanilla Vista install include the 16-bit DEBUG.COM?
4. What's the concern about temp files? All it takes is something like

set tf="%TEMP%\%~0.tmp"
somecommand > %tf%
:
del %tf%

so a set command and a delete command. Not exactly huge, unwieldy
overhead.

 

[Dean Wells \(MVP\)]

...

Raises a few questions.

1. May cscript now be considered a core utility?
2. How about scripted use of debug?
3. Does a vanilla Vista install include the 16-bit DEBUG.COM?
4. What's the concern about temp files? All it takes is something like

set tf="%TEMP%\%~0.tmp"
somecommand > %tf%
:
del %tf%

so a set command and a delete command. Not exactly huge, unwieldy
overhead.

I'm not sure who you're posing your questions to since my comments were
in response to Herb's list of best-practices but I'm happy to throw in
my opinion ... solicited or otherwise :0) -

1. Yes ... but Vista brings its own concerns to the table.
2. Of course.
3. Yes ... <begin paste>

C:\>ver

Microsoft Windows [Version 6.0.6001]

C:\>debug
-

</paste>

4. Temp files don't particularly concern me, and certainly not to the
point where I'd hesitate using them. I am, however, always conscious of
the complications they introduce but, in many cases, such complications
simply cannot be avoided or they're tolerable (relatively speaking.)
For example, if the script is executed _twice_ (whether deliberately or
inadvertently), logic issues may result since the script may branch
incorrectly based on the content of the TEMP file which is now
out-of-state since the second instance polluted it. Of course, there
are even ways around that with additional logic but ... well, you can
fill in the rest. Anyways, I'll happily volunteer that I'm describing
edge-cases here so I'll shut-up on that topic and close with -- I use
TEMP files almost across the board because, IMO, to not use them
unnecessarily limits functionality.

 

[Herb Martin]

Sheesh ... that's 'sposed to say 'correction' ... man, this could go on
forever ...

<double-checking> ...
<checking again> ...
<submit>

No problem. Below is the part of the message I was
going to send you before you re-replied that you had
it working <grin>

Don't worry about it. Like you this stuff intrigues me...

I do like Harlan's best: works on all OSes without any
temp files etc. -- I would only like it better if that pipe
to find could be removed <grin>

I tested Harlan's on:
Microsoftr Windows VistaT Ultimate
6.0.6001 Service Pack 1 Build 6001

(@for %%d in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
@fsutil fsinfo drivetype %%d | @find "No such " /v


That is the actual (single) line cut from my current batch file as
I switched to his version -- slightly modified by @ signs.

This same line worked on:

Microsoft(R) Windows(R) Server 2003, Enterprise Edition
5.2.3790 Service Pack 2 Build 3790

Microsoft Windows XP Professional
5.1.2600 Service Pack 2 Build 2600

 

[Herb Martin]

I really agree with everything Dean wrote above and in the previous
message except to DEGREE, where I will try a bit harder to avoid
temps. Sets that are complicated only to a small degree.

The only reason I posted "my" preferences was not to say they were
necessarily best practices, but to make explicit my own prejudices
and offer them to anyone who did think they were a good idea (some
are like avoiding "add-on" utilities whenever practical.)

Raises a few questions.

1. May cscript now be considered a core utility?

It's on all modern machines so logically the answer is "Yes", but for
me the answer remains "No", since I don't like VBScript and once
I must make that break I tend to go "all the way to Perl."

Perl is on all of my machines. I am partly responsible for getting
Perl added to the (3.51) Resource Kit and am only sorry that
we didn't get it into the product (almost but the CD-ROM/Build
was already locked for changes by that time.)

2. How about scripted use of debug?

Probably about the same (for me) -- I use to use that back in DOS
days when I didn't always have Perl. One issue with this is that it
changes the Command Prompt size and thus induces a disconcerting
visual effect as it runs and quits.

Truthfully I thought it was gone. <grin>

Exactly the same for EdLin.

3. Does a vanilla Vista install include the 16-bit DEBUG.COM?

Apparently. Mine does.

And I found the other night that it also has EdLin.

I was actually considering using EdLin at one point for THIS problem.

4. What's the concern about temp files? All it takes is something like

set tf="%TEMP%\%~0.tmp"
somecommand > %tf%
:
del %tf%

so a set command and a delete command. Not exactly huge, unwieldy
overhead.

You may consider it mere prejudice on my part. I don't like possible
race considitions with the same file name in mupliple windows, trying to
come up with unique names, clean up if the batch file is aborted, etc

The pseudo environment variable %Random% can (help) solve this at
the expense of more complication....

BTW: I am not a fan (so far) of PowerShell either. (To little, too late,
too slow [to start], not ubiquitous [yet], too awkward.)

 

[Herb Martin]

I'm not sure who you're posing your questions to since my comments were in
response to Herb's list of best-practices but I'm happy to throw in my
opinion ... solicited or otherwise :0) -

Calling my own idiosyncratic list "best-practices" is going much further
than
necessary Dean. <grin>

They are just my practices, some of them perhaps good but nowhere

1. Yes ... but Vista brings its own concerns to the table.
2. Of course.
3. Yes ... <begin paste>

For instance, I agreed with you about CScript but mentioned that I
just don't like it and will go all the way to Perl if CScript proves
necessary.

Exception: If someone gives me a working script which uses CScript
then perhaps I would just use it -- feeling no compulsion to rewrite it.

Microsoft could easiy have added Perl, awk, sed, grep, back in
NT 3.51 and this would all be so much easier.