Re: Learning Windows 2000 batch - Windows NT

This is a discussion on Re: Learning Windows 2000 batch - Windows NT ; "JClark" wrote > 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: Learning Windows 2000 batch

  1. Re: Learning Windows 2000 batch

    "JClark" wrote
    > 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.


    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!



  2. Re: Learning Windows 2000 batch


    "guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message
    news:bivp1h$di4of$6@ID-170595.news.uni-berlin.de...
    > "JClark" wrote
    > > 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.

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


    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.



    /Al



  3. Re: Learning Windows 2000 batch


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


    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




  4. Re: Learning Windows 2000 batch

    > 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

    --
    Herb Martin

    "Farouk Dindar" wrote in message
    news:KqP4b.653$I_2.145742@news20.bellglobal.com...
    >
    > >> 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.

    >
    > 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
    >
    >
    >




  5. Re: Learning Windows 2000 batch

    "Al Dunbar" wrote in message
    news:u4M4b.883261$3C2.20229885@news3.calgary.shaw. ca...
    >
    > "guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message
    > news:bivp1h$di4of$6@ID-170595.news.uni-berlin.de...
    > > "JClark" wrote
    > > > 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.

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

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


    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!



  6. Re: Learning Windows 2000 batch


    "guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message
    news:bj1og9$e5irs$1@ID-170595.news.uni-berlin.de...
    > "Al Dunbar" wrote in message
    > news:u4M4b.883261$3C2.20229885@news3.calgary.shaw. ca...
    > >
    > > "guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message
    > > news:bivp1h$di4of$6@ID-170595.news.uni-berlin.de...
    > > > "JClark" wrote




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

    >
    > 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).


    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).


    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.


    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



+ Reply to Thread