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

[nickles]

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

 

[Joe Caverly]

SETLOCAL and ENDLOCAL both work from the command line. From the help;

SETLOCAL can be used on the command line, in aliases, and in batch files.

Also http://jpsoft.com/forums/threads/setlocal-can-be-used-on-the-command-line.5107/

Joe

 

[dcantor]

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

Why not just pass the value directly as

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

command %@eval[ some expression involving existing variables ]

 

[nickles]

I would prefer not to do that as I would have to recompute a static expression for every line to be printed...

 

[Steve Fabian]

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.

 

[nickles]

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.

 

[Steve Fabian]

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.

 

[nickles]

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