[drixomanbeta]

Hi,

before I say anything, yes I know this seem to have been asked multiple time but bear with me. I'm a definite newb at this...

anyway...I've found this little code that I think would satisfy navigating to the installation source directory with the GUIRunOnce in winnt.sif (I have no doubt this look very familiar to you experts on here)

for %%a in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%a:\yourfile.xyz set CDROM=%%a

I thought, why couldn't I just call cmd.exe from GUIRunOnce, passing the above statement (which would normally be ran in a separate batch file) as a parameter (or "echo" it into the prompt and ran, if that's pretty much the same thing...) instead of putting that in a separate file having to be copied from $OEM$ folder.

Any idea how to do this? I must admit I have NO skill with the command prompt at all that can be even close to help here....

Thanks.

[Yzöwl]

SET will not set a variable beyond the current session so you cannot simply set a variable which can be used in future command sessions. Each line you create under GUIRunOnce will be a different command session. If you wish to work directly from GUIRunOnce, you'd have to do it all in one single line of commands concatenated as required.

[drixomanbeta]

Well...I was just thinking to use it to call on one batch file only on my disc. I'm not planning to run all my command with just one long concatenate by calling on cmd at RunOnce.

[Yzöwl]

If you create a directory, SCRIPTS, in for instance, YourCD:\SUPPORT\TOOLS you can place MyScript.cmd inside it and run something like this from winnt.sif:

[GuiRunOnce]
	DetachedProgram = CMD.EXE
	Arguments = "/Q /C FOR /F %# IN ('%SYSTEMROOT%\SYSTEM32\MOUNTVOL.EXE^|FINDSTR [C-Z]:\\') DO IF EXIST %#WIN51 CALL %#SUPPORT\TOOLS\SCRIPTS\MyScript.cmd"

The above is three lines in total.

That should run the script from your CDROM meaning that all commands within that script can be designed to be local to the CDROM e.g. %~d0

[drixomanbeta]

Hi, sorry for being a little late...

I tried your code above but it doesn't seem to be able to find the file that my batch file is suppose to start.

I first tried it in installation, then I just tried it in plain Windows with a Run dialog with the following

%SYSTEMROOT%\SYSTEM32\cmd.exe /Q /C FOR /F %# IN ('%SYSTEMROOT%\SYSTEM32\MOUNTVOL.EXE^|FINDSTR [C-Z]:\\') DO IF EXIST %#WIN51 CALL %#PostInstall.cmd

The master batch PostInstall is at the root of CD, and it's suppose to "START /wait" a couple of program:

the line in the batch program is : Start /wait UPDATE\3whateverprogram\whateverprogram.exe /parameter

Both pretty much give the same result of not finding what the Start command is suppose to find. Simply running the batch file from the cd's root has no such problem.

Any idea how to fix this?

Thanks

[Yzöwl]

Can you provide a directory listing? Type the following into a command prompt and copy/paste the output into your response.

for %# in (%systemdrive% X:) do @(echo/---%#---&dir/b/a/og %#)

Replace X with the drive letter for your inserted unattended media

[drixomanbeta]

I skipped the Systemdrive part, was that required?

---G:---
$OEM$
VALUEADD
UPDATE
DOCS
I386
SUPPORT
cmpnents
PostInstall.cmd
Last Session_u.ini
SETUP.EXE
Last Session.ini
BOOTFONT.BIN
AUTORUN.INF
WIN51
WIN51IP
README.HTM
setupxp.htm
win51ip.SP2
win51ip.SP3

Sorry for some editing there, I moved my batch file into a folder later on but still the same problem. I now moved it back.

This post has been edited by drixomanbeta: 07 February 2012 - 08:53 PM

[Yzöwl]

Now the exact contents, (no editing), of your PostInstall.cmd.

[drixomanbeta]

Here's the batch file:

CLS
@echo off
TITLE Post Install

ECHO Installing KB
ECHO Please Wait...

start /wait UPDATE\977816\update\update.exe /norestart /passive /nobackup
start /wait UPDATE\n2656353.msp  /norestart /passive 
(there's other stuff in the same format as above here)

EXIT

[Yzöwl]

What happens if you change the content of PostInstall.cmd temporarily to:

@ECHO OFF
TITLE Testing Script
ECHO=%%CDROM%%=%~d0
ECHO=Delaying tactics employed
PING -n 11 127.0.0.1 1>NUL

BTW, which part of exact contents and no editing did you not understand?

[drixomanbeta]

Oh sorry about that. It's just that I have the same line repeated many time with different program in different folders. You can ignore that bracketed line.

Do you want me to change the batch to what you provided there and call it with the Run dialog with the parameter you provided earlier?

[Yzöwl]

Yes, but run it from a command prompt not the run box.

FOR /F %# IN ('MOUNTVOL^|FINDSTR [C-Z]:\\') DO IF EXIST %#PostInstall.cmd CALL %#PostInstall.cmd

recreate the original set-up, replacing only the content of the batch file. This should isolate the problem area to either your batch file or the implementation of the set-up.

[drixomanbeta]

Yzöwl, on 09 February 2012 - 03:57 PM, said:

Yes, but run it from a command prompt not the run box.

FOR /F %# IN ('MOUNTVOL^|FINDSTR [C-Z]:\\') DO IF EXIST %#PostInstall.cmd CALL %#PostInstall.cmd

recreate the original set-up, replacing only the content of the batch file. This should isolate the problem area to either your batch file or the implementation of the set-up.

okay...I replaced my batch with your ping test and ran the for loop from a prompt. Here's what happens:

D:\Documents and Settings\Drix>IF EXIST C:\PostInstall.cmd CALL C:\PostInstall.c
md

D:\Documents and Settings\Drix>IF EXIST D:\PostInstall.cmd CALL D:\PostInstall.c
md

D:\Documents and Settings\Drix>IF EXIST E:\PostInstall.cmd CALL E:\PostInstall.c
md

D:\Documents and Settings\Drix>IF EXIST G:\PostInstall.cmd CALL G:\PostInstall.c
md
%CDROM%=G:
Delaying tactics employed

From there it just exit and return to the prompt. My (virtual) disc drive is G: (Daemon Tools Lite)
Just my opinion but I don't think there's anything wrong with my batch file, seeing that it works no problem if it's just dbl-clicked on (even as burned to CD, so it's probably not related to batch and the set-up's file structure).

[Yzöwl]

The command I gave you which runs the batch file is seen to have worked and the batch content I provided is seen to have worked.

Since the folder structure you provided contains the tag file required I can see only two likely problems, your winnt.sif or your PostInstall.cmd. If you are convinced that your batch script, (the content of which you have hidden from us), is okay then your issue is with the .sif file. However since you reported the script not running from my command earlier, and your folder structure clearly shows it should with a working command line, I am not ruling out the script as the most likely problem.

In order to find a solution, attach both files exactly as they are to be examined, otherwise you are on your own.

[drixomanbeta]

I have posted my batch file earlier, could you not see it?

I'm pretty sure my batch (should) have no problem, seeing that if you just run it normally from explorer all the start commands works, as the target program are all called as relative path.

It's just that when it is called by your parameter it seems to have lost track of its "starting location" or something. I wouldn't think we need to examine the sif file as even not in installation mode I'm unable to get my batch to perform as it should with your command there, so it's doubtful that it's an installation issue.
But here's the two file you requested: I changed the sif to have it run at T-9 instead of GuiRunOnce, but that shouldn't matter since the same problem of my batch not finding directory structure correctly persist. The problem it seems is rather fundamental and I'm not expecting it to change with different timing of the call to the batch.

Attached File(s)

•  Pinstall.cmd (2.34K)
  Number of downloads: 7
•  WINNT.sif (490bytes)
  Number of downloads: 11

[Yzöwl]

I gave you the entries for GuiRunOnce as requested but you decided to go it alone, so you have your wish!

[bphlpt]

@drixomanbeta -

I counted at least five times in this thread where Yzöwl asked you to do or report something specific, and you decided to do or report something different, always saying "but that shouldn't matter...". Yzöwl has decided, since you obviously feel you know what should or shouldn't be done, that you must not need any help, and I think everyone else here agrees with him. We will be curious to learn what you eventually find to be the problem Who knows? We might learn something.

In the future, if you ask someone to help, and they graciously offer to give you advice, here or elsewhere:

First - Take it. Do not edit it, do not change it, do not question it, do not try a shortcut, do not ask why, do not think, just do it and report exactly what happened. There are usually good reasons why you are being asked to do or report something specific.

Then - Propose alternatives, ask questions, show what happens when you do it a different way. In the exchange of data, in both directions, we can both learn something. But if you won't listen to us, then why should we listen to you?

Please let us know when you find a solution.

Cheers and Regards

[drixomanbeta]

In fact I did found the problem, and the solution. You wouldn't (would you?) believe how simple it was...(and how dumb I was.)

The problem: in my batch file I kept relative path when I should have used full, like so: start /wait %~d0\UPDATE\... Problem solved.

Apparently it did not occur to the unenlightened me of what y'all here would probably have thought of as 1+1

Then again, when I said I was a newb, I really did meant it. How come this batch worked when ran on its own while called on by prompt it fails? Anyway...

To that end...I still don't understand how %~d0 actually work (yes I searched for it...something about %n special enviro variable...way out of my league to comprehend )

Anyway, thanks for the help here; consider my question answered. At least if some other simpleton like me asked these silly type of question...well they won't have to torment you experts for too much with this particular case. (I probably should have sticked to svcpack rather than setupparams. I obviously don't know the difference (except I know I have some other stuff from addonpacks being called at T-13; don't want to mess up that).

"I'm a simple man. I do not possess a [compsci] degree nor am I [algorithmically] inclined." ~George Carlin.

[Yzöwl]

drixomanbeta, on 19 February 2012 - 01:13 AM, said:

In fact I did found the problem, and the solution. You wouldn't (would you?) believe how simple it was...(and how dumb I was.)

The problem: in my batch file I kept relative path when I should have used full, like so: start /wait %~d0\UPDATE\... Problem solved.

I had already told you to do that too!

Yzöwl, on 29 January 2012 - 07:45 AM, said:

That should run the script from your CDROM meaning that all commands within that script can be designed to be local to the CDROM e.g. %~d0

Thanks for posting back and for providing closure to the problem, it means that other readers with the same or similar problem can use the advice given in the knowledge that it is known to work!