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

Passing a variable to a command w/o adding it to the local environment

Discussion in 'Support' started by nickles, Nov 21, 2013.

  1. nickles

    Joined:
    Jun 24, 2008
    Messages:
    220
    Likes Received:
    0
    How would I pass a variable to a command w/o adding it to the local environment?

    E.g. so far:

    set x=4 & command : command "consumes" %x

    Problem: After "set x", %x is contained in the calling process's environment (unlik e.g. in Linux).

    Note: This is going to be a one-liner used to call a PDIR function, not a batch file, so using SETLOCAL will not work...
     
  2. Joe Caverly

    Joined:
    Aug 28, 2009
    Messages:
    680
    Likes Received:
    8
  3. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    Why not just pass the value directly as
    Code:
    command 4
    
    Whatever the value is, even if it's an expression, you don't need to compute the value and assign it to a variable, you can just put the computation into the line invoking your external command, like
    Code:
    command %@eval[ some expression involving existing variables ]
    
     
  4. nickles

    Joined:
    Jun 24, 2008
    Messages:
    220
    Likes Received:
    0
    I would prefer not to do that as I would have to recompute a static expression for every line to be printed...
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Well, you cannot have your cake and eat it, too... But wait: there are other ways then e.v.-s to save a string value, use it multiple times, and discard it. For example, you can store the string value in an alias, and use the @alias[] function to inset the string in the command. This is esp. convenient if you do not use global aliases (at least while this particular scheme is used).

    If you gave us a more detailed example, we might be able to provide more assistance.
     
  6. nickles

    Joined:
    Jun 24, 2008
    Messages:
    220
    Likes Received:
    0
    Here you go:

    function sfpn = `%@instr[%1,%@unquotes[%2]]`
    alias lrd = `set YYSFPNLEN=%@len[%@full[%%1]] & pdir /a /ogen /ne /d /s /(dd.m.y th:m zc a -13fN @sfpn[%YYSFPNLEN%,*])`
    lrd <path_containing_dirs>

    The setup prints just the relative file name (i.e. stripping off the biggtest common leading substring). After the first execution there's an additional variable YYSFPNLEN in the environment. Using alias (didn't try it though) would probably leave me with another alias definition, which were likewise undesireable.
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    I have a logically similar alias:
    ctr is an alias : *pdir /ne /d /p/ogne/a:-d/(@filestamp[*] zc @relfile[*])
    where
    relfile is a function: %@quote[%@replace[%_cwds,,%@full[%&]]]
    The major limitation of my CTR compared with your LRD is that you must make the search base directory your default directory.

    The extra few milliseconds to evaluate @sfpn for every file is negligible compare with disk access times.
    alias lrd = `pdir /a /ogen /ne /d /s /(dd.m.y th:m zc a -13fN @sfpn[%%@len[%%@full[%1]],*])`

    Comments:
    1/ Your definition of function SFPN seems incorrect, @INSTR has 3 parameters, not 2 - but the 2nd one could be an empty string. Probably the 2nd comma "," was dropped during copy-and-paste. To drop the left %1 characters of string %2 you could also use @right[-%1,%2]...
    2/ The path you display is LFN, not SFN. Of course, you may be as traditional as I am and use only SFN-conforming paths, when possible.
     
  8. nickles

    Joined:
    Jun 24, 2008
    Messages:
    220
    Likes Received:
    0
    @Steve

    Thanks for your comments.

    For the first one: I indeed missed to see that (TCC didn't complain, and the function worked as intended - but I learned why @substr[] was deprecated for @instr[] ;-).
    For the second one: Despite of the name (SFN), I prefer to see [semi(?)] "long" names (the chosen name is therefore somewhat inappropriate/misleading).

    So in general: My "construct" does what I want it to do... BUT

    1) Although your statement in respect to disk access times compared to computation times is certainly correct (if we neglect the possibility that the directory's contents may already be in the OS's directory cache), I have a strong dislike "to be forced" to code like this (hence the variable, hence this thread).
    2) My intention was to find out if variables might be used like I use to use them in bash, where it is perfectly normal to create "volatile" variables with a limited scope.

    A "simple" solution might be if Rex would add another pdir field... (or some more ;-).
     

Share This Page