1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixed Using %~dp1 for paths with unavailable drives

Discussion in 'Support' started by RoyIvyIII, Dec 11, 2011.

  1. RoyIvyIII

    Joined:
    Feb 12, 2009
    Messages:
    4
    Likes Received:
    0
    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
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  3. RoyIvyIII

    Joined:
    Feb 12, 2009
    Messages:
    4
    Likes Received:
    0
    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?
     
  4. RoyIvyIII

    Joined:
    Feb 12, 2009
    Messages:
    4
    Likes Received:
    0
    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?
     

    Attached Files:

  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Yes.

    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.

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

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    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 likes this.
  7. RoyIvyIII

    Joined:
    Feb 12, 2009
    Messages:
    4
    Likes Received:
    0

    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.


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


    @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
     

Share This Page