Numbering Lines with FIND


Numbering lines accomplishes two things: (1) It makes each line unique (so you can use FIND to extract a particular line), and (2) It "poisons" each line, insuring that the first word will not be a valid command or legitimate argument for a command. 

Both FIND and FC can be used with their /N options to number lines for you. Here are typical commands and outputs using a "DIR.TXT" file generated by the output of my DIR \DOS\*.COM /OS > DIR.TXT command.

FIND /N " " < DIR.TXT gives the following output:

[2] Volume in drive C is MS-DOS 
[3] Volume Serial Number is 20A4-6627 
[4] Directory of C:\DOS 
[6]HELP     COM           413  03-10-93  6:00a HELP.COM 
[7]LOADFIX  COM         1,131  03-10-93  6:00a LOADFIX.COM 
[8]DOSSHELL COM         4,620  03-10-93  6:00a DOSSHELL.COM 
[9]TREE     COM         6,945  05-31-94  6:22a TREE.COM 
[10]DISKCOMP COM        10,748  05-31-94  6:22a DISKCOMP.COM 
[11]UNFORMAT COM        12,738  03-10-93  6:00a UNFORMAT.COM 
[12]GRAPHICS COM        19,742  05-31-94  6:22a GRAPHICS.COM 
[13]COMMAND  COM        54,645  05-31-94  6:22a COMMAND.COM 
[14]VSAFE    COM        62,576  03-10-93  6:00a VSAFE.COM 
[15]         9 file(s)        173,558 bytes 
[16]         0 dir(s)     258,334,720 bytes free
The advantage of using FIND is that it could have accepted input piping, eliminating the need for the intermediate DIR.TXT file. You may have to adjust your FIND string to make sure it returns all the lines (For example, a reverse search for a very unlikely string). Since I searched for lines containing spaces, I did not return blank lines (Notice the missing lines numbered 1 and 5). The disadvantage of FIND is that it affixes its numbers to the beginning of the line, effectively ruining the first word of each line.

FC /N DIR.TXT NUL gives the following output:

Comparing files dir.txt and NUL 
****** dir.txt
     1: 
     2:   Volume in drive C is MS-DOS 
     3:   Volume Serial Number is 20A4-6627 
     4:   Directory of C:\DOS 
     5: 
     6:  HELP     COM           413  03-10-93  6:00a HELP.COM 
     7:  LOADFIX  COM         1,131  03-10-93  6:00a LOADFIX.COM 
     8:  DOSSHELL COM         4,620  03-10-93  6:00a DOSSHELL.COM 
     9:  TREE     COM         6,945  05-31-94  6:22a TREE.COM 
    10:  DISKCOMP COM        10,748  05-31-94  6:22a DISKCOMP.COM 
    11:  UNFORMAT COM        12,738  03-10-93  6:00a UNFORMAT.COM 
    12:  GRAPHICS COM        19,742  05-31-94  6:22a GRAPHICS.COM 
    13:  COMMAND  COM        54,645  05-31-94  6:22a COMMAND.COM 
    14:  VSAFE    COM        62,576  03-10-93  6:00a VSAFE.COM 
    15:           9 file(s)        173,558 bytes 
    16:           0 dir(s)     258,334,720 bytes free 
****** NUL 
******
FC is used here to compare the file against the "NUL" device. It numbers all the differing lines. Since NUL always contains nothing, all the lines in DIR.TXT will differ and they will all be numbered -- even the blank ones.

Regardless of whether FIND or FC is used, the lines are now all unique! If I wanted the first file name, it would always be on line six. If I had used FC, I could search for "     6:  ". If I had used FIND, I could search for "[6]". Likewise, since the numbering poisoned each line (making sure the first word is not a valid command, device, date, etc.), I could pass them all as commands to a separate command processor or pass them as arguments to commands.

Lost? Look at the site map.

Bad links? Questions? Send me mail.

Google
Yahoo
Ask Jeeves