[.cmd] find drive, set path, execute w/ params

Thought this may be useful for anyone else trying to Script a shortcut to an executable on an external drive with unknown drive letter. A shortcut merely needs to point to the .cmd in the System32 folder on the System Drive.

Being my first .cmd, any ideas or improvements are welcome.

[codebox]Run,"%Scriptfile%",Set_Path,<path (no drive)>,<filename (no extension)> [Set_Path] #--- &#39;#1&#39; => path (no drive); &#39;#2&#39; => filename (no extension) ---# If,NotExistFile,"%TargetDir%\Windows\system32\#2.cmd",FileCreateBlank,"%TargetDir%\Windows\system32\#2.cmd" TxtAddLine,"%TargetDir%\Windows\system32\#2.cmd","@ECHO OFF","Append" TxtAddLine,"%TargetDir%\Windows\system32\#2.cmd","SETLOCAL","Append" TxtAddLine,"%TargetDir%\Windows\system32\#2.cmd","for #$p#$pi in (Z Y X W V U T S R Q P O N M L K J I H G F E D C) do if exist #$p#$pi:\#1\#2.exe set Prog_Drive=#$p#$pi","Append" TxtAddLine,"%TargetDir%\Windows\system32\#2.cmd","set path=#$pProg_Drive#$p:\#1;#$pPATH#$p","Append" TxtAddLine,"%TargetDir%\Windows\system32\#2.cmd","#$pProg_Drive#$p:\#1\#2.exe #$p1 #$p2 #$p3 #$p4 #$p5 #$p6 #$p7 #$p8 #$p9","Append" TxtAddLine,"%TargetDir%\Windows\system32\#2.cmd","ENDLOCAL","Append" #\------------------------------------------------------------------------/#[/codebox] Translates to (for example): [codebox]@ECHO OFF SETLOCAL
for %%i in (Z Y X W V U T S R Q P O N M L K J I H G F E D C) do if exist %%i:\Tools\image.exe set Prog_Drive=%%i
set path=%Prog_Drive%:\Tools;%PATH%
%Prog_Drive%:\Tools\image.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
ENDLOCAL[/codebox]


Regards

Instead of running a cmd before starting each program on the external drive. Not to mention the Problem with the shortcut icon or the problem in case the program needs to have it's workfolder defined.

Run the cmd via runonceex and change it to add a new variable. Something like ExtDrive maybe.
Then all shortcuts to the external drive can use %ExtDrive%\Folder\Folder\File.exe .

Nice.

A few things though, since you asked for it :

Being my first .cmd, any ideas or improvements are welcome.

1) Is it necessary to use the SETLOCAL and modify the path?
2) Is it not the idea of "%1 %2 %3 %4 %5 %6 %7 %8 %9" that of passing to the program ALL parameters?
3) Can the shortcut invoke the command passing parameters?
4) Is it not needed something like cmdow to hide the DOS window?

In other words, would something like this work ?:

@ECHO OFF

:: This .cmd must be invoked with a parameter pointing to a 

:: executable file, including RELATIVE path, such as:

:: \Tools\image.exe

:: BEFORE any parameter the executable might need



SET target=%1

SHIFT

SET params=%*

SETLOCAL ENABLEEXTENSIONS

FOR %%A in (Z Y X W V U T S R Q P O N M L K J I H G F E D C) DO (

IF EXIST %%A:%target% SET target=%%A:%target%&GOTO :File_found

)

ECHO Destination NOT found!&PAUSE

GOTO :EOF



:File_found

CALL :Run_file %target%

GOTO :EOF



:Run_file

ECHO %1

PUSHD %~p1

::If the batch works, delete following two lines

ECHO %~nx1 %params%

PAUSE

::and UNREM following one

REM %~nx1 %params%

GOTO :EOF

Anyway, exiting the FOR loop as soon as a valid value is found should be faster, expecially if the drive letter is between one of the "high" ones, and this way you need just one .cmd (and several shortcuts) as opposed to several .cmd's, one for each shortcut.

jaclaz

@MedEvil

ATM, just testing from the command-line with command-line apps like peimg, diskpart, imagex and pkgmgr...

... I'll give your suggestion some thought.

The first problem was setting the PATH. For example, copy the whole "Servicing" folder from WAIK to run from CD. The folder includes a stack of dll files on which pkgmgr (and peimg too) depends. 'set path=' is not persistent! There are only a few ways around it, like manually editing the registry or using setx.exe. Or, maybe, copying the dll files into the pre-existing PATH.

The actual shortcuts to the .cmd files are created at build-time with a little vbs script. Nothing more to do at run-time.

Thanks

The actual shortcuts to the .cmd files are created at build-time with a little vbs script. Nothing more to do at run-time.

Do not spend too much time into creating shortcuts by API during build time!

I'm currently thinking about replacing the API build by a 'manual / programmatically' creation of the .lnk file.

The main reason: If during build time API build the target file is not at the pace the shortcut points to, usually something in the shortcut becomes wrong. Usually the Explorer Icon is shown only after the first use of the shortcut.

Therfore in your current 'external storage' shortcuts I'm always waiting for some issues.

Peter

The first problem was setting the PATH. For example, copy the whole "Servicing" folder from WAIK to run from CD. The folder includes a stack of dll files on which pkgmgr (and peimg too) depends. 'set path=' is not persistent! There are only a few ways around it, like manually editing the registry or using setx.exe. Or, maybe, copying the dll files into the pre-existing PATH.

Yep, that's the idea behind changing to target directory (if it works ) instead of changing the PATH environment variable, maybe a .local file is needed.

jaclaz

Sorry jaclaz... our posts crossed over.

To quickly answer your Qs before another cross...

1. SETLOCAL is not necessary, but, without it, each time the .cmd is called from the same Command Prompt instance, the %PATH% acquires a repeat of the new path. Like 'D:\Tools;D:\Tools;D:\Tools;X:\Windows...' looks untidy!

2. The same [Set_Path] Section of the Script is used (called by) every app in the Script. Looking at some of the apps, it is possible that nine parameters may be required - maybe I'm exaggerating a bit! They don't all need to be used.

3. The shortcuts themselves have the parameters. Only tested so far is /? which brings up the correct help screens. Some apps - for example, sys.exe, I think it was - require at least one parameter to avoid an error message.

4. Just tested with command-line apps, so the Command Window is a necessity. I will try to find out what a 'cmdow' is exactly.

... and a lot more time will be required to decipher your code.

Thanks

Do not spend too much time into creating shortcuts by API during build time!

I'm currently thinking about replacing the API build by a 'manual / programmatically' creation of the .lnk file.

I am not using the API... I don't think. Do you mean th api.script/script.project combo?

I use a .vbs script of my own making. There aren't many other ways to create the shortcuts (.lnk files).

Thanks

I'm currently thinking about replacing the API build by a 'manual / programmatically' creation of the .lnk file.

The main reason: If during build time API build the target file is not at the pace the shortcut points to, usually something in the shortcut becomes wrong. Usually the Explorer Icon is shown only after the first use of the shortcut.

Not again!
Where the heck do you get this strange error always from?
I thought, we solved this issue once and for all, about a year ago!

I am not using the API... I don't think. Do you mean th api.script/script.project combo?

I use a .vbs script of my own making. There aren't many other ways to create the shortcuts (.lnk files).

Thanks

No, I mean the API given us by Bill G.

Peter

Not again!
Where the heck do you get this strange error always from?
I thought, we solved this issue once and for all, about a year ago!

Only by some 'unserious' codings I made inside she shortcut apps. So we have a time bomb ...

And I'm since a couple of month thinking about the 'manual' solution I mentioned above.
But

• Priority:
  • the time bomb did not explode until now
  • nobody detected the time bomb until now
• Interest
  • I prefer working with nativeEx_puzzleXP and nativeEx_BSOR, getting a 'lower level' knowledge how Bill's setup works

(Every questions for explaining the time bomb, are unanswered )

Peter

Here is the Script to create the fail-safe .vbs script for creating shortcuts. It's from Bill himself.

[codebox][Mke_Shrtcut_Script] Echo,"Making Shortcut Script (.vbs)" FileCreateBlank,"%ProjectDir%\Shrtcut_Script.vbs" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","Set#$sShell#$s=#$sCreateObject(#$qWScript.Shell#$q)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","Set#$slink#$s=#$sShell.CreateShortcut(Wscript.Arguments.Item(0))","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.TargetPath#$s=#$sWscript.Arguments.Item(1)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.WorkingDirectory#$s=#$sWscript.Arguments.Item(2)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.Arguments#$s=#$sWscript.Arguments.Item(3)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.Description#$s=#$sWscript.Arguments.Item(4)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.IconLocation#$s=#$sWscript.Arguments.Item(5)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.WindowStyle#$s=#$sWscript.Arguments.Item(6)","Append" TXTAddLine,"%ProjectDir%\Shrtcut_Script.vbs","link.Save","Append" #\------------------------------------------------------------------------/#[/codebox]


... but Mr Norton may not like it.

Sorry jaclaz... our posts crossed over.

To quickly answer your Qs before another cross...

1. SETLOCAL is not necessary, but, without it, each time the .cmd is called from the same Command Prompt instance, the %PATH% acquires a repeat of the new path. Like 'D:\Tools;D:\Tools;D:\Tools;X:\Windows...' looks untidy!

I wasn't "against" the "SETLOCAL" I am "against" changes to the PATH environment variable, IF invoking a .exe from it's working directory is enough.

Looky here (cmdow or similar):
http://www.boot-land...?...ic=85&st=26
http://www.boot-land...?showtopic=3155
http://www.boot-land...?...c=3155&st=7

... and a lot more time will be required to decipher your code.

Feel free to ask about anything you are unfamiliar with.

jaclaz

Here is the Script to create the fail-safe .vbs script for creating shortcuts. It's from Bill himself.

.....


... but Mr Norton may not like it.

I agree to Mr. Norton:

Imagine: Your Link.TargetPath = "M:\Programs"

If I understand correctly:
You only generate a script here, you do not create a shortcut.

If you execute the script in build time, this issue may appear:
If during the run of your VS there is no "M:\Programs" on your local system, something in the final link is wrong.
In most cases the last character of the path is lost.

If you execute the script in boot time, it generates the shortcuts successfully. But then you may have troubles, if the OS source CD you used for PE build, does not have the same language like that one you used for installing your host OS.
(Maybe in case of a German source, your app is now in M:\Programme rather than M:\Programs)

And please believe me: I do not accept 'that happens rarely'. I do want to make Scripts / apps which are 100% independent of 'OS assumptions'.

(Sorry, sometimes I get some error reports showing me, that I did someting wrong in 'independent')

Peter

You only generate a script here, you do not create a shortcut.

Yes. Parameters (arguments) are quoted and space-separated. For example:

ShellExecute,Hide,"%ScriptDir%\Shrtcut_Script.vbs","#$q%TargetDir%\ProgramData\Microsoft\Windows\Start#$sMenu\Programs\Startup\StartNet.lnk #$q#$s#$qcmd.exe#$q#$s#$q#$q#$s#$q/c#$sstartnet.cmd#$q#$s#$qStartNet#$sCmd#$q#$s#$qcmd.exe#$q#$s1"

If you execute the script in build time, this issue may appear:If during the run of your VS there is no "M:\Programs" on your local system, something in the final link is wrong.In most cases the last character of the path is lost.

I have not had that happen, but I wil keep an eye out for this issue. When executed at build-time, no target is required to exist. I know that it is impossible to manually create shortcuts for non-existent targets.

If you execute the script in boot time, itgenerates the shortcuts successfully. But then you may have troubles, if the OS source CD you used for PE build, does not have the same language like that one you used for installing your host OS.

I haven't tried starting the .vbs Script at boot-time because it likely requires Scripting Host which I am unsure about.

As for the question about Languages... no idea, and no way to test it.

Regards

For example:

....

That is exactly what buildModel or the corresponding API script by pedrole are doing at build time.

Therefore, when you create the shortcut during build time, I do not see any difference.

Or: Am I'm going to become blind?

Maybe you try both ways and do a binary compare of the resulting *.lnk.

If they are different, please post the files here.

Peter

I edited a few posts to make the thread "better looking".

@allanf
Instead of the [ code ] - [ / code ] tags, use the [ codebox ] - [ / codebox ] tags when you post looong lines of code, this way you can avoid the _ substitution thingie and code can be copied and pasted easily.

@All
Since the "stupid", and I will never refrain at every possible occasion to remark the absolute lack of professionality of the IP.Board developers for having produced such a terrible thing, update, besides my Opera not working anymore with MOST if not all of the "easy" buttons, strange thing happen.

If you post something like:

Hallo, this text is inside a codebox!

and you later edit the post the result, after submitting the edited post, will be something like this:
<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>
Hallo, this text is inside a codebox!
</div>

In other words, the smart guys are changing automatically the good ol' board language to some sort of HTML or XML that THEIR OWN SOFTWARE cannot interpreter correctly.

jaclaz

Or: Am I'm going to become blind?

No. You probably have good eyes. Perhaps a parameter is missing or out of place. I haven't used the buildModel, and can't compare. I imagine a .lnk is a .lnk.

As I understand it, the VistaPE vpeldr, which I have used, creates the shortcuts at boot time, and assumed that the buildModel is the same.

There is nothing secret about the Script I have posted... open and transparent.

Since the "stupid", and I will never refrain at every possible occasion to remark the absolute lack of professionality of the IP.Board developers for having produced such a terrible thing, update, besides my Opera not working anymore with MOST if not all of the "easy" buttons, strange thing happen.

... later edit the post the result, after submitting the edited post, will be something like this:
...
<div ... /div>
In other words, the smart guys are changing automatically the good ol' board language to some sort of HTML or XML that THEIR OWN SOFTWARE cannot interpreter correctly. w00t.gif

You should try to reply to your (unchanged) post

Since a while I before editing, I copy the actual content into Textpad, and rebuild CODEBOXes. Frustrating, but that works!

Peter

Following another current discussion about shortcut icons here, I discovered that the .vbs script is able to select any icon index number.

For clarity, here is the .vbs created by the Winbuilder Script posted earlier.

[codebox]Set Shell = CreateObject("WScript.Shell")Set link = Shell.CreateShortcut(Wscript.Arguments.Item(0))link.TargetPath = Wscript.Arguments.Item(1)link.WorkingDirectory = Wscript.Arguments.Item(2)link.Arguments = Wscript.Arguments.Item(3)link.Description = Wscript.Arguments.Item(4)link.IconLocation = Wscript.Arguments.Item(5)link.WindowStyle = Wscript.Arguments.Item(6)link.Save[/codebox]Copy and paste it to a txt file and rename to MakeShortCut.vbs (best on the desktop). Open Command Prompt and navigate to the directory. Type:[code]MakeShortCut.vbs &#34;test.lnk&#34; &#34;m&#58;\anywhere\nofile.txt&#34; &#34;m&#58;\anywhere&#34; &#34;/jumpUp&#34; &#34;testLnk&#34; &#34;%systemroot%\system32\shell32.dll,-6&#34; &#34;1&#34;[/code]

... and a shortcut will appear. Change the icon index to '6' (without '-') or another number, and the icon will change. Double-click it and errors will appear because the target does not exist.

Getting back to the original topic - I think that jaclaz has answered two questions that I was looking for - how to exit the loop, and how to have multiple commands in the 'for' statement. Thanks. I cannot try it out until after the weekend.

BTW. I have only have the right half of my Display working. The other half looks like men from Mars are trying to communicate, and big black bar with pinstripes right down the middle. That's why the line-breaks were there... for others in the same situation.

Now I'm "scrolling along, singin' a song..."

Thanks

Instead of running a cmd before starting each program on the external drive. Not to mention the Problem with the shortcut icon or the problem in case the program needs to have it's workfolder defined.

Run the cmd via runonceex and change it to add a new variable. Something like ExtDrive maybe.
Then all shortcuts to the external drive can use %ExtDrive%\Folder\Folder\File.exe .

MedEvil,

You're right. Now that I have moved to non-command-line apps, I see that there is no way - no easy way? - to specify the shortcut's icon at build-time. ... And the working directory, I have not begun to think about.

Something needs to be run at boot-time.

In my earlier attempts, I ran the looping .cmd at boot-time (placed in the startup folder with emergeDesktop Shell, rather than runonceEx), and noticed that it had no effect when a fresh instance of Command Window was started - the looping .cmd had to be run again in each instance of the Command Window. So, I came up with the idea of a separate .cmd (with the loop) for each Shortcut.

jaclaz has provided a solution using a single .cmd that works with non-command-line apps (not counting the missing shortcut properties that need to point to an unknown drive letter). It may be possible to make it apply to command-line apps as well, by manipulating the looping .cmd parameters to have the executable as 'cmd.exe' in a known location and it's parameters as the apps in unknown locations. Currently, the apps are found, but the Command Window needs to be held open - ' /k' is OK for most apps, but '/c' is better for diskpart which presents itself in a 'sub-instance' (?) within the Command Window. ... sorry for the lack of proper terminology.

There must be a simple and elegent, open solution to the Icon problem, avoiding registry editing and setx.exe. It may take me some time to find it. ... just thought I'd give an update.

Thanks

Its been my experience with genshortcuts, which generates xpe shortcuts at build time, that as long as all directories ( program, start directory, icon ) are referenced via an environment variable like %SystemDrive% that the lnk file generates ok. If you put an actual drive letter in any of the paths then the windows api will corrupt the lnk file at build time if the actual referenced path does not exist.

Its been my experience with genshortcuts, which generates xpe shortcuts at build time, that as long as all directories ( program, start directory, icon ) are referenced via an environment variable like %SystemDrive% that the lnk file generates ok. If you put an actual drive letter in any of the paths then the windows api will corrupt the lnk file at build time if the actual referenced path does not exist.

Hi paraglider,

It's been a while since I built BartPE... had the same disc for ages. I am guessing that the shortcuts are created then moved or copied? That may cause the corruption in cases where an actual drive letter is specified?

The Winbuilder Project that I am working on creates the shortcuts in situ in the Target Folder which is then wrapped up with imagex. I have not had a problem with the .vbs script, but I have only used pre-set environment variables to define the path to the target, so I can't really say whether there is a similar issue.

BTW. Do you known of a Boot Script to set a permanent Environment Variable to an external drive with a varying Drive Letter? I'm getting a bit worried that there may not be a simple solution.

Thanks

I always precreate mine on the CD and configure the start menu to run from the CD. All I know is that anytime problems with genshortcuts have been reported its always been the case that absolute paths were used in the shortcut. At the same time on the same CD others that were created with environment variables for the drive worked.

I don't know of a tool to find the mounted drive although it must be possible to differentiate between real drives and mounted drives.

... If during the run of your VS there is no "M:\Programs" on your local system, something in the final link is wrong.
In most cases the last character of the path is lost.

This is interesting from MS KB:

The Create Shortcut command truncates the source path folder names to eight characters

This problem can occur because the shell cannot determine whether the hard disk supports long file names, so the path is truncated to be acceptable to all file systems.

... and a strange work-around for .vbs using 'Subst j: c:\' to make a non-existent drive 'j:\' exist temporarily.

Regards