Best way to extend (System) %path% for own apps

Hi,

I've created a small but useful script for quickly changing a dynamically assigned IP address.

Now I'd like to append %PE_Programs%\%ProgramFolder% to the path variable, enabling me to directly launch reconnect.cmd in a cmd shell. I'm looking for a simple yet flexible way to achieve this, maybe without tampering with the Registry...?
As I've got more command line tools I'd like to access via %path%, I need this possibility several times.

Thanks in advance!

Any (best) practice tip whatsoever...?

To launch an application without supplying a full path, it needs to be located in the path. Either (a) add the path to the registry; or (b) add the program to a location already in the path, eg to system32.

Regards,
Galapo.

Either (a) add the path to the registry; or (b) add the program to a location already in the path, eg to system32.

IMHO, (b) isn't the best way to go.
And (a) means I would have to modify REG_EXPAND_SZ value Path in [HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment] which I'd like to avoid. (Also unsure about the usage of variables there, original system variables like %SystemDrive% versus WB variables like %PE_Programs%\%ProgramFolder% ...)

I though of a command like

Setx Path "%path%;X:\Program Files\My little tool"

which could be executed as Autorun or something similar... Is this feasible somehow?
It should work for both RunfromRAM and RunfromCD apps.

Or did I miss something?

Which works for RunFromCD, RunFromRam,  and reconnect.cmd not in the path (eg: system32), I do not really see.
Here is a piece of code to create a new environment variable %Programs% in addition to %ProgramFiles% and use one or the other.

Code: [Select]

[Process]
RegHiveLoad,Tmp_Default,%RegDefault%
RegWrite,HKLM,0x2,Tmp_Default\Environment,Programs,Y:\Programs
RegHiveUnLoad,Tmp_Default

RegHiveLoad,Tmp_System,%RegSystem%
RegWrite,HKLM,0x2,"Tmp_System\ControlSet001\Control\Session Manager\Environment",Programs,Y:\Programs
RegHiveUnLoad,Tmp_System

I though of a command like

Setx Path "%path%;X:\Program Files\My little tool"

which could be executed as Autorun or something similar... Is this feasible somehow?
It should work for both RunfromRAM and RunfromCD apps.

That command won't work since you've hardcoded 'X:\Program Files' and that won't always work between RunFromCD and RunFromRam.

Test

Code: [Select]

Setx Path "%path%;%PE_Programs%\%ProgramFolder%"and see what it does. That will need to be run before your CMD file.

Regards,
Galapo.

I just understand the idea with setx, to test in PE.

Code: [Select]

[Interface]
ScrollBox_RunFromWhere="Run from CD",1,4,4,9,148,21,"Run default","Run from RAM","Run from CD"

[Process]
Echo,"Processing %ScriptTitle%..."
StrFormat,REPLACE,%ScrollBox_RunFromWhere%," ","",%runfrom%
If,Not,%runfrom%,Equal,Rundefault,Call,VariableToMacro,%runfrom%,True
TXTDelLine,%target_sys%\autorun.cmd,exit
TXTAddLine,%target_sys%\autorun.cmd,"Setx #$pPath#$p #$q#$ppath#$p;%PE_Programs%\%ProgramFolder%#$q",Append
TXTAddLine,%target_sys%\autorun.cmd,exit,Append

RunFromRam -> Setx %Path% "%path%;%SystemDrive%\Program Files\MyApps"
RunFromCD -> Setx %Path% "%path%;Y:\Programs\MyApps"

Salut ChrisR,

if I understood you correctly, you suggested writing a setx line into the file autorun.cmd to customize %path%, didn't you?

As setx.exe won't get copied to %target_sys% by default, I enforced it at the beginning of my test script.
However, it turned out, that executing setx.exe (automatically or later by me) has no effect.

Here's what I did in a cmd shell:
X:\> path
PATH=X:\windows\system32;X:\windows;X:\windows\System32\Wbem

X:\> setx PATH "%PATH%;Y:\Programs\Reconnect"
SUCCESS: Value has been written*

X:\> path
PATH=X:\windows\system32;X:\windows;X:\windows\System32\Wbem
* Roughly translated from german (i.e. not the precise output)

I have no clue what's going wrong, are there any ideas?


UPDATE:
The little switch -m seems to do the trick, I'm off, re-testing...........

However, it turned out, that executing setx.exe (automatically or later by me) has no effect.

You need to open a new cmd windows to see the result.

I do not use specially Setx, careful with user and/or system, it seems to duplicate from system path to user path.

:cheers 

Thanks, ChrisR.

It's exactly this %target_sys%\autorun.cmd I was after, it seems to work as expected
Update: Unfortunately only for the last element.
Calling setx two times, the first one gets lost, despite the fact that autorun.cmd holds both (correct) setx commands...

I don't know why or when this error occurs, my autorun.cmd reads:

@echo off
drvload.exe X:\Windows\inf\battery.inf
Setx Path "%Path%;Y:\Programs\Reconnect" /m
Setx Path "%Path%;%SystemDrive%:\Program Files\JohnTheRipper" /m
drvload.exe X:\Windows\inf\HDARt.inf
drvload.exe X:\Windows\inf\hdaudio.inf
[…]
exit

Now path shows up as:
PATH=X:\windows\system32;X:\windows;X:\windows\System32\Wbem;X:\Program Files\JohnTheRipper

The first Setx line was either ignored or reversed afterwards somehow. (Both Setx lines work separately, by the way, and it doesn't matter if RunfromRAM or RunfromCD is set.)
I guess <layman's_terms>changes made with Setx… /M aren't immediately written to the Registry, so the latter Setx call neutralizes former ones</layman's_terms>.

Is there a chance to correct this behaviour somehow?
For instance, creating a temporary %PathAdds%, stuffing all the path extension(s) in it and finalizing with Setx... not knowing all WB details, is that possible?

Hi Mikka,

better you provide your "plugin underconstruction" to get better support,
since there are various ways to get things work on the area you are working on.
 

It would be good Indeed, to share your script under construction in order to better help you.
What is your goal, you want to add the path for each Apps ? Attention to the limit of 1024 characters in this case 


For your issue with setX (called several times), you can try an alternative Setenv.exe  , it should work better in your case.

you have an old Setenv.exe from Vincent Fatica here http://barnyard.syr.edu/~vefatica/

and another Setenv version from Jonathan Wilkes here http://www.codeproject.com/Articles/12153/SetEnv
which should better meet your need for the path with the prefix % for expanded variables.

SetEnv -ua Path %y:\Programs\Folder
Path=%Path%;y:\Programs\Folder   <== if needed in the current DOS window

Code: [Select]

... RunFromWhere ...
TXTDelLine,%target_sys%\autorun.cmd,exit
TXTAddLine,%target_sys%\autorun.cmd,"SetEnv -ua Path #$p%PE_Programs%\%ProgramFolder%#$q",Append
TXTAddLine,%target_sys%\autorun.cmd,"Path=#$pPath#$p;%PE_Programs%\%ProgramFolder%",Append
TXTAddLine,%target_sys%\autorun.cmd,exit,Append

half tested

Thank you for the feedback!

Well, I'm just having quite a few developping problems as I keep working on several scripts.
(I did finish an all new Firefox universal script and the plugin integration gave me some headaches...)

This setx thing, however, I don't understand at all. I try to outline what I do:

[…]
[Variables]
%ProgramEXE%=reconnect.cmd
%ProgramFolder%=Reconnect
%ProgramTitle%=Reconnect
%SetupFile%=reconnect.7z

[Process]
StrFormat,Replace,%ScrollBox_RunFrom%," ","",%_run_%
If,Not,%_run_%,Equal,Rundefault,Call,VariableToMacro,%_run_%,True
Unpack,,Archive,Folder,%SetupFile%,%Target_Prog%\%ProgramFolder%
##Let's add that program to the System Path:
If,%CheckBoxPath%,Equal,True,Begin
  If,Not,ExistFile,%target_sys%\setx.exe,Require_FileQ,setx.exe
  ##As the following line doesn't work, I hardcoded both drive and path base...
  //IniRead,"%ProjectDir%\script.project","Variables","#$pPE_Programs#$p",%_runrunrun_%
  TXTDelLine,%target_sys%\autorun.cmd,exit
  //TXTAddLine,%target_sys%\autorun.cmd,"Setx Path #$q#$pPath#$p;%_runrunrun_%\%ProgramFolder%#$q /m",Append
  If,%ScrollBox_RunFrom%,Equal,"Run from RAM",Begin
    TXTAddLine,%target_sys%\autorun.cmd,"Setx Path #$q#$pPath#$p;X:\Program Files\%ProgramFolder%#$q /m",Append
  End
  Else,Begin
    TXTAddLine,%target_sys%\autorun.cmd,"Setx Path #$q#$pPath#$p;Y:\Programs\%ProgramFolder%#$q /m",Append
  End
  TXTAddLine,%target_sys%\autorun.cmd,exit,Append
End
[…]

This works (at least as long as %_runrunrun_% is not involved...) as expected, with the build (correctly) having X:\Program Files\Reconnect as last entry of Path—that means for this particular program. Unless WB processes a chain of scripts and each one appends a new entry: I did tests with the additional John The Ripper script (for demonstration purposes only), for the result see my post above.

Although all setx lines got written into autorun.cmd, it seems just the last entry is actually applied.
I haven't yet checked concurrent programs like setenv.exe, I probably should, though...

There might also be a logical error in the code above, what's your opinion?

Hi Mikka,

as I wrote, it is better you provide the plugin under construction, I see you use wrong hardcoded lines, but I do not know why...

I also made some cmd utilities, batches etc for some applications, never had such problem and always have easy ways to do... (as you see others too)

anyway, as I wrote, provide your plugin under construction, than one would easly make things work in right way and you will learn 

Right, the following scripts are to be considered as "beta" and won't be bug-free.

Here we go:

here you go
http://www.mediafire.com/download.php?nojx37pknucxbj8

just used Script Create Packed with some minor additions 

all you need is starting a cmd window on the application folder, no need setx blabla etc.
above plugins will guide you nicely and I hope you start using SC Packed 

btw, do not download applications unless they are <100 megabytes or you have to (legal)....
we are old enough to see, application servers down , servers change, application sold or changed radically etc... which makes weblinks unusable ;) as a result plugins unusable, that is the reason you find many plugins with embedded apps 
and when plugin written nice, updating is quite easy, which you will see on John The Ripper plugin 
(also you recently practiced, even highly complex Opera plugin can be updated easly since written nicely  )

 

You're right, other scripts of mine provide an option to use local installers.

Note that the John the Ripper script was originally written by SkyBeam and just slightly modified (graphic, new url) by me. Moreover, JtR was given as a second example script for my path problem.
As JtR can't be reasonably used other than per command line, I thought it would suit best to demonstrate the cause. In fact, it may be any other command line based program.
Scrutinizing your rewrites, I fail to see an improvement. However, what you did is ditching the paths functionality: This is not what I want!
It's that very issue I want to solve, the whole rest was okay and didn't need greater changes...

It's that very issue I want to solve, the whole rest was okay and didn't need greater changes...

so the only issue is your hoby curiosity, since things works without it, there is no real issue ;)

From my past experience here are some notes:
adding a path to environment registry, requires broadcasting to system too, which I guess setx on your case do.
But keep in mind, on active cmd window, I guess when you use setx (which makes both reg add and broadcast) active cmd window not effected, you need to start a new cmd window.
The workaround is either
a) do your env. change work on a seperate cmd first (Galapo also mentioned on reply 5) than start a new cmd window for your task
b) do your env. change work on startup Add_Shortcut,Autorun etc... (ChrisR already wrote SetEnv with autorun.cmd)
c) or on single cmd window use set and setx together for same path (since set command gets active cmd window )
d) there is buildtime addition available, ChrisR already gave an example on reply 4

ps:
using

Code: [Select]

cd /D"%~dp0"

may be useful on your cmd tasks.......

My past related experience can be found here 
especially check topic post and reply7
http://theoven.org/index.php?topic=100.0



I never need such setx kind things on PE for apps, never seen someone need too, besides if needed it is not hard to get operational such thing with available options but only a tricky windows thingy ;) ,
opening cmd window on desired path always enough for cmd applications,
simple solution for simple goals, which is the only improvment on plugins in addition to tidy up codes, took only some minutes to prepare instead of checking your codes line by line, I only checked your plugin to see if anything special required for any apps, which I see none, and only took logos 

 

Well, it's not just theory, I have a precise purpose in mind.

The Reconnect script (yet quite basic) currently holds a printip executable to print out the current extern IP address.
An everyday task is launching a command prompt and typing printip (just an example, I guess the printip call will be extended, too), and dependant on this, running further commands.
(This is also useful when checking proxys or testing VPNs.)

Thanks ChrisR for the tip of SetEnv/CodeProject: it turned out that it always does what I want without botching.
Great! Why doesn't Microsoft offer an equally good tool?