Fixed Using %~dp1 for paths with unavailable drives

[RoyIvyIII]

In writing a function to parse arbitrary paths, I'm encountering an error for paths with drives which are unavailable (such as a path on a disconnected network drive).

An example of the function is:

:FN
setlocal
set p=%~dp1
...
goto :EOF

All variations on "%~dp1" and trying to use an expression based on %@full[%1] cause errors:

TCC: (Sys) The system cannot find the drive specified.
"X:"

This looks like a parsing error as I can only suppress it using a command group (eg, enclosing parenthesis).

CMD.exe works correctly, without complaint, but I want the function to work with TCC as well.

Is this a bug? Any suggestions on a work-around to avoid the pre-parsing?

Thanks, in advance.

- Roy

 

[rconn]

WAD. TCC checks at the time of the definition, and returns an error if the drive reference fails. CMD ignores the error at the time of definition, and fails mysteriously when you actually try to use the value later.

 

[RoyIvyIII]

WAD = works as designed?

Not to be argumentative, but I've tested this and CMD _doesn't_ error _or_ "mysteriously fail". It correctly parses the string whether the drive exists or not. I have test calls with arbitrary paths that prove it.

And so, the question still stands... I can parse an arbitrary string into drive letter, path, name, extension with CMD, but have almost unsuppressable errors with TCC. I am amenable to special coding for TCC in the subroutine, if necessary. Do you have any way to parse an arbitrary path for the noted pieces, without emitting spurious errors?

 

[RoyIvyIII]

I've attached a BAT test file which demonstrates that CMD works, and produces correct results, with arbitrary paths, whether the drive/path/file exists or not. Executing the same BAT with TCC fails with loud, difficult to suppress, error messages.

Any ideas/suggestions how to fix this?

 

[rconn]

WAD = works as designed?

Yes.

Not to be argumentative, but I've tested this and CMD _doesn't_ error _or_ "mysteriously fail". It correctly parses the string whether the drive exists or not. I have test calls with arbitrary paths that prove it.

CMD parses the string; it just fails mysteriously when you actually try to *use* it somewhere. If the drive doesn't exist when you're parsing the string, it probably still doesn't exist when you're trying to use the string.

And so, the question still stands... I can parse an arbitrary string into drive letter, path, name, extension with CMD, but have almost unsuppressable errors with TCC. I am amenable to special coding for TCC in the subroutine, if necessary. Do you have any way to parse an arbitrary path for the noted pieces, without emitting spurious errors?

There's no way to tell TCC to pretend that a nonexistent drive might exist at some future time. You can use @ready[] to see if a drive is actually available.

 

[samintz]

I'm not sure if this is what you are looking for:
[R:\] dir i:

TCC: (Sys) The device is not ready.
"I:\"

[R:\] echo %@filename[I:\foo\bar.bat]
bar.bat

[R:\] echo %@path[I:\foo\bar.bat]
I:\foo\

-Scott

 

[RoyIvyIII]

CMD parses the string; it just fails mysteriously when you actually try to *use* it somewhere. If the drive doesn't exist when you're parsing the string, it probably still doesn't exist when you're trying to use the string.

I appreciate that you've taken the time to read my question and respond. But, that's incorrect. It is very possible that a location could be accessible at a later time, both during the execution of the script ("net use ...") or at a later time if the results are saved in the environment or registry.

And if the results are used appropriately (eg, using "IF EXIST ..." gates or simply using the PATH components for some other reason), there is no "mysterious fail". Any result is simply a string to be used (or misused) just like any other.

There's no way to tell TCC to pretend that a nonexistent drive might exist at some future time. You can use @ready[] to see if a drive is actually available.

@ready[] is too blunt an instrument to help as it returns false even for drives that will execute @full[] without errors (eg, BD/DVD/CD-ROM drives without media).

[R:\] echo %@path[I:\foo\bar.bat]
I:\foo\

@samintz, Thanks for the serious reply. I'd tried that method, and while it avoids the TCC parsing error messages, it doesn't have exactly the same semantics as the standard parameter options. Specifically, it fails to parse and fixup "." and ".." within the paths (the standard parameter options do this internal parse/fixup).

Ultimately, I have solved this by noting when TCC is the script parser, pre-parsing the argument string in those instances (pulling off the drive, if any, and changing it to the current drive), and then concatenating the original drive with the result. This strategy avoids all TCC errors and gives me correct results, which are equivalent whether using TCC or CMD.

- Roy