SET commands

[Podde]

I am trying to get some SET commands to work in other CMD´s then the one actually executed from,
but with various results.

From one cmd without any SETLOCAL I have the lines;

set str=%~d0%~p0
set str=%str:~2,-6%
set sourcedrv=%~d0%str%source\
set str=
set update=%1

I would then prefer to have this SET´s to work within another CMD, but for some reason it looks that
it is not passed over.

I would be happy if someone explained what I´ve missed or the limitations of environment variables in Windows 7.

//Peter

[Rileyh]

Peter,
I do not quite understand what you are talking about when you mention "another cmd"
There is only one cmd/command prompt, so what do you mean by that ?
Secondly, what is the "%~"?
Thirdly, what do you want this code to do? Is this an excerpt from a batch file or is it one in itself?
Answer that and then I might be able to help you.

[aGerman]

@Rileyh
%~d0 will be expanded to the drive of the currently running batch file while %~p0 is expanded to the path. You could also combine it to %~dp0.

@Podde
Actually I don't understand your problem.

Regards
aGerman

[Podde]

Thanks for taking the time to answer.

I do run a lot of portable applications but got tired of having my files infected so
I started to making password protected RAR files. Whenever I want to use some
of the applications, they will be extracted to %temp%, executed and then deleted.

However, some applications needs to update it´s source rar-file, as for example
the FTP program when adding a new host. All of this works fine with Windows XP
but not with Windows 7.

I must have a way to always knowing the path to the source, driveletter changes
from time to time and with different PC´s as well.

When an applications is to be used I have an icon that links to a start.cmd on the stick
and with the help of having %1 as application name, extracts the RAR file to "%temp%\folderx"
and then starts a run.cmd within this newly created folder.

This start.cmd contains the code below to set the path to the files on my USB stick.

set str=%~d0%~p0
set str=%str:~2,-6%
set sourcedrv=%~d0%str%source\
set update=%1

When finishing the application, the run.cmd uses rar.exe to detects if anything changed and updates
the original RAR archive on the stick with the help of above SET´s.

So...a start.cmd makes some SET commands to knowing the path back to the stick, it will the fire up
a run.cmd that, if needed, updates the source RAR on the stick. If loosing %sourcedrv% the archive
wont be updated.

Sorry for making it so long and again, thanks for your time.

//Peter

[aGerman]

OK, but where does it fail? Or didn't you check whether the variables are incorrect?

Code: Select all

@echo off
set str=%~d0%~p0
echo %str%
set str=%str:~2,-6%
echo %str%
set sourcedrv=%~d0%str%source\
echo %sourcedrv%
pause

Regards
aGerman

[Acy Forsythe]

What he's saying is that the cmd environment is not saving his variables from one instance of cmd to the next.

The original batch file that unrars the app has all of that information, but later if that application needs an update, it's very possible the path has changed and the update script has no idea where the app is.

If that's correct, then there are several ways around that.

1. Store the information in a text file.
2. Create permanent environmental variables.
3. Store the info in the registry.

There are other ways, but those are the first 3 that come to my mind.

[alan_b]

Perhaps the problem is that when CMD.EXE is launched it can add new SET variables to its own environment,
but making that environment subsequently available to other instances of CMD.EXE is impossible at my skill level.

What I can do is use a script that creates new SET variables and then CALL or START another script to use the same environment.

[Acy Forsythe]

I'm with you Alan, to my knowledge you can't "Set" your environment permanently. The registry is my preferred method of saving user specific permanent data that I need to access via batch.

We'll have to wait for Podde to respond, but I get the feeling, that there is a delay between script1 and script2 so calling 2 from 1 is not common, only when he needs to update one of his unrar'd apps.

[aGerman]

You can always CALL another batch file to work with the same environment.
bat1.bat

Code: Select all

@echo off
set /a var1=1
echo I'm bat1.
echo My current var environment:
set var
echo I'm going to CALL bat2
echo(

call bat2.bat 2

echo This is bat1 again.
echo My current var environment:
set var
echo(

pause

bat2.bat

Code: Select all

@echo off
set /a var%1=%1
echo I'm bat2.
echo My var environment:
set var
echo(

If you run the bat2 in another cmd instance (e.g. via START) then bat2 will inherit the environment of bat1. But you cannot pass changings back to the parent environment.

Regards
aGerman