What I want to do is to provide Novell-equipped customers
with an application note on how to start our software from a
login script, but I've noticed that the Novell Windows
Client documentation doesn't quite tell all that one should
know about running a .Bat file from a Novell login script.
For one thing, the documentation fails to point out that the
file given in a "#" command may actually only be a binary
executable, such as a .com or .exe file, not a .bat file.
Apparently one needs to run the system command-shell
(COMMAND.COM or CMD.EXE) to run the .bat file.
So, to be independent of whether the client is Windows 9x or
NT/2000/XP, something like this is required; assuming that
X: has been mapped to a network drive, and that startfpp.bat
is the bat file I wish to run:
SET LOGINNAME=%CN
#%<comspec> /c x:\startfpp.bat
I can find no examples of anything like this in the Novell
documentation, but this is what we've come up with. So, my
question is: Do I have this right, or is there some other
more "elegant" way to do this? In other words, what is
regarded as the "best practice" for running .bat files from
login scripts?
BTW, the SET command is there because the .bat file runs a
program that needs to receive the Netware login name in an
environment variable.
Incidently, someone needs to tell Novell that their
documentation fails to tell how to run a .bat file. It
currently implies that the Windows command shell is used to
execute "#" commands, and it obviously is not. We had to
figure this out on our own.
Quoting from the document (Novell Client for Windows
Installation and Administration Guide, October 2001,
103-000159-001):
--------begin quote-------
# [path] filename [parameter]
Replace path with a drive letter, or, if you have specified
NOSWAP on the
command line or in the login script, you can replace path
with a full directory
path beginning with the NetWare volume name.
Replace filename with an executable file (files that end in
.EXE, .COM, or
.BAT, for example). It isn't necessary to include the
extension, but doing so
can speed up the execution of the external program.
Replace parameter with any parameters that must accompany
the executable
file.
---------end quote-----------
The way the software apparently works, saying that it
supports .bat files directly is false.
--
Russ Holsclaw
Lead Software Engineer
Fast Data Technology, Inc.
(please reply to newsgroup)
#I:\sysup\MS03-026\w2k\update\update.bat
If you lead the command with a "#", the login script will wait until
that program finishes executing before going on to the next command. If
you lead it with a "@", the login script will call the external program,
and also continue running the script.
In my case, I called this RPC patch, which would auto-reboot the
workstation, so I did not want the login script to do anything else.
In your case, try #x:\startfpp.bat or @x:\startfpp.bat. Either one
should work. Using the @ will make the login process appear to go
faster, as other processes will run concurrently with your batch file.
If these "other processes" seem to butt heads with your batch file, then
lead it with the pound sign instead.
-Sean
No good... when I tried to run a bat file this way, I got an
error message to the effect that the file was not
executable. The writeup for the message said that the named
file had to be either a .COM or .EXE file. We were not able
to get a .bat file to run unless we ran it under "cmd.exe
/c" (or "Command /c" for Win 98).
I'm running Netware 6.0 here by the way. Is it possible that
things have changed with this version?
The # and @ commands can only be used to run executables - not batch files.
So you need to do #<command processor> /C "batch file to execute"
--
Hamish Speirs
Novell Support Forums Volunteer Sysop.
(No email unless requested please)
The way you have it is fine - other option is to combine it all into one
command:
#%<comspec> /c "x:\startfpp.bat" %CN
Then in the .bat file access the parameter via %1
Interesting idea. It's actually a program started by the
.bat file that needs the environment variable, and we've
just modified it so it can be told which environment
variable to pick up the UserID from. I decided that this was
easier than using Novell's dll calls to pick up the ID.
Since our program is designed to run in all networks, not
just Novell's, we decided against using Novell-specific
interfaces within the code itself.
Thanks for confirming the basic idea of what we're doing.
if os="WNT" and <ncver>="4.83" and <ncsp><"sp1"
#I:\SYSUP\NCLIENT\NCLIENT.BAT
if os="WNT" and <ncver><"4.83" #I:\SYSUP\NCLIENT\NCLIENT.BAT
I'm getting the NCVER and NCSP values with REGREAD, BTW.
TID 10013491 provides this example:
The login script should look like this: #<path>\FILE.BAT
TID 10054915 provides this example:
IF MEMBER OF "GWUPDATE" THEN
#f:\public\gwupdate.bat
I'm only providing 2 examples instead of 1 because on rare occasions
something incorrect makes it into a TID (but eventally gets caught).
-Sean
Interesting - I'm sure it didn't used to execute batch files - then again my
memory could be going <g>