Learning Windows 2000 batch

  • Thread starter Thread starter JClark
  • Start date Start date
J

JClark

While you knowledgeable guys are near your computers, perhaps you
could direct me to a textbook or even a web source for learning about
Windows batch files. My old DOS books don't seem to apply to the new
stuff I'm reading about in recent replies.
Thanks again.

Jack
 
JClark said:
While you knowledgeable guys are near your computers, perhaps you
could direct me to a textbook or even a web source for learning about
Windows batch files. My old DOS books don't seem to apply to the new
stuff I'm reading about in recent replies.
Thanks again.

Jack
Click to expand...

The 'standard' textbook is Tim Hill's _Windows NT Shell Scripting_.

As Walter pointed out, jsiinc has a lot of batch files, plus a great
deal of other very helpful and useful material.

Here are a few good web sites:

http://www.seanet.com/~shardy/ntscript.html
Win NT CMD programming

http://www.ss64.com/nt/
Simon Sheppard's WinNT Command Reference

http://www.robvanderwoude.com/
Rob van der Woude's Scripting Pages: Batch Files for DOS, Windows (all flavors), and OS/2
 
While you knowledgeable guys are near your computers, perhaps you
could direct me to a textbook or even a web source for learning about
Windows batch files. My old DOS books don't seem to apply to the new
stuff I'm reading about in recent replies.
Click to expand...

One of the biggest challenges you will face when writing shell scripts is
learning the many inconsistencies and "special cases" associated with each
NT-based platform. While the NT/2K/XP/K3 shell scripting environment is
MUCH more powerful than DOS or Windows 95/98/ME, the lack of certain "basic"
features can cause much Fuming.

In addition, many environments prohibit third-party tools due to security
and/or stability concerns. Whether you agree or disagree with this policy,
it is a reality that Windows SysAdmins have to deal with every day.

And finally, many tools (free or otherwise) provide the same functionality
that is ALREADY AVAILABLE in a default installation. The reason that they
are widely used is because getting the information that you want, packaged
in a way you can use, using only the builtin utilities, is SUCH A FUMING
CHORE!

Here's what we recommend (some of these are FREE and some are "Almost
Free" - from $9 to as little as $1 per system).

*******
#1 - Write your scripts using Mount/\Commands

..Mount/\Commands are extensions to the "builtin"
commands and utilities that are present on
ALL INSTALLATIONS of all NT-based operating
systems including Windows NT4 SP6a+, 2000,
XP and Server 2003.

They are constructed entirely of builtin commands
common to all four platforms (NT/2K/XP/K3).
There is NO BINARY CODE, only scripting commands!

They can be run on any NT4 or later installation
RIGHT OUT OF THE BOX! A single file contains
the entire Mount/\Command Set and they can be
loaded or unloaded as a group in under 2 seconds
on a typically loaded system.

..Mount/\Commands are specifically designed for
use in shell scripts and are coded for
Compatibility, Clarity and Speed.

Compatibility means that ALL M/\Cs perform
CONSISTENTLY across NT/2K/XP/K3. When the
command is created, those aggravating special
cases (the source of much Fuming) are masked
within the M/\C code so that a
CONSISTENT RESULT IS ALWAYS OBTAINED.

Clarity means that scripting code written
using MountCommands can be easily understood
and maintained, even by those without
extensive shell scripting experience.

Speed means that all available methods are
employed to enhance the performance of each
command, including preloading the code so
NO DISK ACCESS is needed to invoke it!
(just like the internal commands such as
FOR, ECHO, DIR, etc.)

The complete Mount/\Command Set contains over 200
of these powerful commands. For more information,
see (http://MountCommands.com).

*******
#2 - Learn structured scripting techniques.

Our Free KnowledgeLetter, "BoomingOrFuming?" provides
valuable knowledge regarding the creation and maintenance
of reliable cross-platform shell scripts.

Subscribers also receive FREE versions of our
Pattern Scripts that help you to create your own
custom Mount/\Commands to add to the Standard Set.

You can find the sample issues at
(http://BoomingOrFuming.com)

*******
#3 - Get the FREE Advanced NT/2K/XP Command Library (ntlib.cmd)

ntlib.cmd provides over 50 sample Mount/\Commands
to assist with writing and documenting shell scripts.
To get your FREE copy, go to (http://ntlib.com).

*******
You will also want to take a look at TheGuardBook,
Online Reference for Cross-Platform Shell Scripting at
(http://TheSystemGuard.com/TheGuardBook/CCS-Int).

All the commands internal to cmd.exe are documented
here in "Mounted Help" pages. This includes a
color-keyed page highlighting the differences
among all internal commands in NT/2K/XP/K3. The
"Common Help" from each OS's help screen is also
available for comparison.

*******
-tsg
____________________________________________________________
TheSystemGuard.com | BoomingOrFuming.com | MountCommands.com
Free and "Almost Free" Knowledge for Windows System Admins!
 
guard said:
One of the biggest challenges you will face when writing shell scripts is
learning the many inconsistencies and "special cases" associated with each
NT-based platform. While the NT/2K/XP/K3 shell scripting environment is
MUCH more powerful than DOS or Windows 95/98/ME, the lack of certain "basic"
features can cause much Fuming.

In addition, many environments prohibit third-party tools due to security
and/or stability concerns.
Click to expand...

Please note that, even though the products being sold by Mr. "guard" are
plain text batch files (not that they are easy to read), they *ARE*
third-party, and *SOME* system managers may not allow them until they have
been fully regression tested in your particular environment. Regardless,
installing and running them without following whatever approval process your
company has *COULD* be considered a violation.

<snip>

/Al
 
While you knowledgeable guys are near your computers, perhaps you
could direct me to a textbook or even a web source for learning about
Windows batch files. My old DOS books don't seem to apply to the new
stuff I'm reading about in recent replies.
Thanks again.

Jack
Click to expand...
Whew! That's some assignment, guys!. I've copied the references and
hope to get some time to start. Many thanks for the thoughtful
replies.

Jack
 
I have written a few simple batch files with copy and
xcopy commands and appropriate switches. They work.

If a file name is longer that 8.3 dos file that put them in quotes

Farouk Dindar
 
If a file name is longer that 8.3 dos file that put them in quotes

I don't believe that is necessary -- or sufficient if you have problems
with the name.

If the name has no spaces (or other odd characters perhaps) you
don't need the quote -- if the name is longer than 8.3 and some
program won't use it then the spaces won't help there either.

Use quotes to solve the "file name with spaces.txt" problem; use
the "Short name" to solve the 8.3 problem OR to avoid the
spaces problem...

How to find the short name:

dir /x
 
Al Dunbar said:
Please note that, even though the products being sold by Mr. "guard" are
plain text batch files (not that they are easy to read), they *ARE*
third-party, and *SOME* system managers may not allow them until they have
been fully regression tested in your particular environment. Regardless,
installing and running them without following whatever approval process your
company has *COULD* be considered a violation.
Click to expand...

Clarification:

Our experience has been that if our client is permitted to write and run
shell scripts (.cmd files) in their environment, there has been no issue
with using our Command Libraries (NTCmdLib.cmd, ntlib.cmd) or the
Mount/\Command Set (MtCmds.cmd) since these are, in fact, shell scripts.
This is one of the MAIN REASONS for using the product in the first place
(i.e., add no additional software to the standard install).

A solution that is obtained from a "third-party" usenet "answerer" is
frequently "cut and pasted" into a script by the original poster. The
person who asked the question frequently has NO EARTHLY IDEA how the code he
or she is "cutting and pasting" works. They are just thankful for today's
piece of bread (but they'll be hungry again tomorrow since no one has shown
them how to bake their own bread).

*******

In any case, we DO have a program where we share our Command Source
(.cmdsrc) files under non-disclosure with some of our larger clients
(usually limited to those with over 1000 licensed copies but we do make
occasional exceptions). Frequently, these types of institutions are using
our code as the basis for their own extended library and have modified and
tweaked the various Procedures, FUNCTIONS and Mount/\Commands for their
specific environment.

This relieves the central System Admins from having to write and maintain
all the shell scripts. Since the "batch file" syntax is GREATLY SIMPLIFIED,
many end-users and local SysAdmins can now RELIABLY WRITE AND MAINTAIN their
own scripts using templates supplied by the SysAdmin. Central control of
the Command Library and it's documentation is still maintained by the IT
Department, and individual library resources can be adjusted once without
changing all the scripts that use them.

*******

-tsg
____________________________________________________________
TheSystemGuard.com | BoomingOrFuming.com | MountCommands.com
Free and "Almost Free" Knowledge for Windows System Admins!
 
guard said:
Clarification:

Our experience has been that if our client is permitted to write and run
shell scripts (.cmd files) in their environment, there has been no issue
with using our Command Libraries (NTCmdLib.cmd, ntlib.cmd) or the
Mount/\Command Set (MtCmds.cmd) since these are, in fact, shell scripts.
This is one of the MAIN REASONS for using the product in the first place
(i.e., add no additional software to the standard install).
Click to expand...

Some (even sys admins) would argue that a batch script is, in some ways, a
piece of software. More so for one whose operation is difficult to discern
by reading. This possibility is something of which potential users should be
aware before they commit much time to learning how to use your tools.
A solution that is obtained from a "third-party" usenet "answerer" is
frequently "cut and pasted" into a script by the original poster. The
person who asked the question frequently has NO EARTHLY IDEA how the code he
or she is "cutting and pasting" works. They are just thankful for today's
piece of bread (but they'll be hungry again tomorrow since no one has shown
them how to bake their own bread).
Click to expand...

Third-party answerers who come up with complete, cut-and-paste-ready
solutions are, IME, not the norm as you seem to suggest. Are you actually
there to see the helpee do this unthinking cut-and-pasting? Very often there
is an attempt to explain the why's and the wherefore's of how things work.

IMHO, your solutions require the download of a batch file about the workings
of which even more participants here have "NO EARTHLY IDEA". Your idea of
showing them how to bake their own bread is for them to simply follow your
way of doing things.

Many members of this NG (at least the one I am posting in - I cannot speak
to all those that you have chosen to cross-post your reply to) have a
respectable history of helping people here. Your attitude of superiority and
apparent commercial interest is inappropriate and disrespectful of this fact
and as off-topic here as the ads you post, and is the main reason that so
many of us have filtered your posts out.
In any case, we DO have a program where we share our Command Source
(.cmdsrc) files under non-disclosure with some of our larger clients
(usually limited to those with over 1000 licensed copies but we do make
occasional exceptions). Frequently, these types of institutions are using
our code as the basis for their own extended library and have modified and
tweaked the various Procedures, FUNCTIONS and Mount/\Commands for their
specific environment.

This relieves the central System Admins from having to write and maintain
all the shell scripts. Since the "batch file" syntax is GREATLY SIMPLIFIED,
many end-users and local SysAdmins can now RELIABLY WRITE AND MAINTAIN their
own scripts using templates supplied by the SysAdmin. Central control of
the Command Library and it's documentation is still maintained by the IT
Department, and individual library resources can be adjusted once without
changing all the scripts that use them.
Click to expand...

Good for them and good for you. You have a web-site to communicate with
clients and prospective clients. Is there a chance that you could tone down
your posts here to at least give the impression that you honour the
anti-spam sentiments expressed on your website? Or that you respect the ng
for the value it provides?

I would suggest you avoid the "tutorial" approach, and simply state what the
command does. If people want more information (like detailed documentation)
they can choose to click on a link in your tagline. I would also suggest you
avoid the temptation of spreading "the word" farther than necessary by
adding other somewhat related groups to the post.


/Al
 
While you knowledgeable guys are near your computers, perhaps you
could direct me to a textbook or even a web source for learning about
Windows batch files. My old DOS books don't seem to apply to the new
stuff I'm reading about in recent replies.
Thanks again.

Jack
Click to expand...

See tip 2815 and 5451 in the 'Tips & Tricks' at http://www.jsiinc.com for
how to get to the built-in CMD help.



Jerold Schulman
Windows: General MVP
JSI, Inc.
http://www.jsiinc.com
 
Back
Top