Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Login Script code to run a .bat file

657 views
Skip to first unread message

Russ Holsclaw

unread,
Sep 16, 2003, 1:33:09 PM9/16/03
to
I'm a Novell newbie of sorts. We don't actually run a Novell
network except for development purposes, so we can support
Novell networks with our software product.

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)

Sean

unread,
Sep 16, 2003, 3:17:23 PM9/16/03
to
Here's an example calling a batch file from a login script:

#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

Russ Holsclaw

unread,
Sep 16, 2003, 4:13:51 PM9/16/03
to
> Here's an example calling a batch file from a login
script:
>
> #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.

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?

Hamish

unread,
Sep 16, 2003, 7:00:14 PM9/16/03
to
Sean,

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.

http://speirs.mine.nu

(No email unless requested please)


Hamish

unread,
Sep 16, 2003, 7:02:17 PM9/16/03
to
Russ,

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

Russ Holsclaw

unread,
Sep 17, 2003, 12:24:49 PM9/17/03
to

"Hamish" <Ham...@speirs.mine.nu> wrote in message
news:3F679678...@speirs.mine.nu...

> Russ,
>
> 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.

Sean

unread,
Sep 24, 2003, 10:21:46 AM9/24/03
to
Well, it works in my environment. The desktop support team would let me
know if it didn't! NW6 either SP2 or SP3, Novell client 483 SP1 and SP2.
Here's another example that is working 100%:

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

Hamish

unread,
Sep 24, 2003, 4:14:04 PM9/24/03
to
Sean,

Interesting - I'm sure it didn't used to execute batch files - then again my
memory could be going <g>

0 new messages