I nominate this thread for *censored* of the year award.
In fact, I find it so *censored*-ey that I might even require it's URL as part of a shebang line for BCScript files, heh.
As good as you are: start from scratch and write a new batch for this problem
Why? he has a working AWK solution.
Additionally I might wonder aloud why it is that you prefer batch over VBScript and JScript? your reasoning for awk is that it needs t be downloaded; but VBScript and JScript COME with ALL installations of windows since windows 98SE; any windows install past windows 95 (in fact, windows 95 has an OS update that I believe installs ActiveX Scripting engines such as VBS and JS) can use VBScript files. There is no reason to write a batch file if a working VBS or JS solution is provided, and works better. your statements that they are "easier to understand" are merely expressions of your own opinion and not actually decided through any real experience with people using VBS and batch files. batch files ALWAYS open a command prompt window; this, in and of itself, is enough to scare new users sometimes. VBScript, on the other hand, can be written to use WScript.exe and therefore use dialogs and Inputboxes rather then scary text mode Command prompt UI, so anybody who wouldn't understand VBScript would likely prefer the VBScript solution anyway, which brings up the point that the idea isn't always to educate the person seeking help as to the intricacies if the language, but rather to simply provide a solution; sometimes a batch solution, sometimes VBScript, but there is absolutely, positively, no reason to lean towards batch unless the OP has expressed a EXPLICIT interest in only batch-based solutions, and even in those cases a VBScript can be adapted to run from within a batch script anyway so the point is moot. If the OP then becomes interested in learning VBScript, they can be referred to a number of fine resources. I might even conclude that VBScript is EASIER for a new user to understand; BASIC statements roughly translate into plain english:
For Each Value In Collection
Print Value
Next Value
Is a *censored* of a lot easier to read then:
For /f %%P in (`type collection`) do echo %%P
Sure, they both have similarities, but the batch version is not exactly plain english, there are far too many semantics that would need to be explained, such as why there are percent signs, and of course why it is that when the OP uses the command at the command prompt you need only a single % sign. Batch being "simple" is a huge misperception by a large number of users, even the base language as used in Pure DOS is relatively confusing.
Only language I can think of being more "english-like" then BASIC might be python; I don't have extensive experience but I will not argue the repeated point Ghostdog makes that it is easy t olearn for a beginner. It may not ALWAYS be the best choice (which I believe is where I and ghostdog disagree) but it certainly isn't a bad starting point for anybody.
Batch Is. Trust me, I know from experience that learning batch programming first can become a hurdle later on when learning a less domain-restricted programming language. When I first started with QBASIC after using batch, it took some time to realize that I wasn't writing commands, I was writing statements; my previous experience with batch was certainly only a minor hurdle, but a hurdle nonetheless. It's not necessarily a bad thing to learn batch; it's a bad thing to try to learn another language from the perspective of batch semantics, which I believe would hold true for nearly any programming language; they have different "spirits" to steal the term from Bruce McKinney, Author of "HardCore Visual Basic"; for example, the C "spirit" pretty much says the programmer is in control of everything; memory allocations, deallocations, everything must be done by them, and it is this "total control" concept that lends itself to streamlined, low-level C code. Visual Basic tries to hide a good number of things about windows programming from the programmer, sparing them the troubles of creating and maintaining window handles, sending and recieving window messages, etc. There is of course some allocation to be done, such as dimensioning variables (optional, actually, defaulting to the Single data type in Version 1 and to Variant In versions after, unless a Def
type statement is found in the declarations section of a module, in which case the default type for that module is the specified type), but once a variable goes out of scope, it is automatically destroyed. To some extend, C will do this; for static variables declared within procedures. However, pointers will NOT be automatically deallocated in C and this must be dealt with properly. The "spirit" if batch is the very essence of a "glue" language, that is, calling of a number of programs that were compiled in other languages (things like format, find, etc) in predefined orders, and with very specific and basic Control flow that was pretty much a spaghetti of gotos. It has evolved past this stage but it is still a glue language at it's core, and a glue language is limited in far too many ways to count and at the same time its powerful by the sum of the parts that is happens to glue together.
One of the things that batch can use as a glued piece is AWK, just as VBS code can be written to a file and executed from a batch, so to can AWK be executed from the command line, as an extension of batch.
Consider for a moment that almost every batch program calls into another program to do it's work, and all batch programs rely on cmd.exe to perform at the very least basic interpretation of the file; ther eis no denying that it has limitations, and one of these limitations can be found in text processing. warranted, it CAN do text processing, but it takes experience and patience to get it working; on the other hand, scripting languages like VBS have a number of string functions at their disposal, and their Date/time manipulation is simply not matched by any feasible batch solution.
