That would probably be a good idea. Here goes. I had built a module that allows me to copy files that have their archive bit set to a storage medium. Now imagine a directory on your computer for, say, credit card statements. You either scan or download a year’s worth of statements and save them as a single file (pdf, by necessity). At the end of the year you wish to archive them, and recover the space on your hard drive so it doesn’t get filled up. BUT, you need to retain the CC Statement directory for new statements. The module I coded allowed me to not only copy such files, but to also clear their archive bit and then delete them. I also needed to create a Table of Contents to go with the storage medium. Here’s the information I wanted in the TOC: 1) Path to directory holding the file(s); 2)File name; 3)File type (extension); 4)file size in KB; 5)Date created. I coded two cmdlets that did this, but they both have some shortcomings. One works fine where everything of interest is in a single folder. The files are listed alphabetically. In this case, the cmdlet doesn’t show the directory path, which would be repeated for every file… superfluous information. If you know where the folder lives on the hard drive, and what its name is, that’s fine. The second cmdlet does show the directory path - for every file - and while the folder names provide important context to the file names (Think how many files begin with “miscellaneous.”), it’s still a lot of extra information.
Now enter Don Jones, and his two ConvertTo-EnhancedHTML cmdlets. I bought his book “Creating HTML Reports in Powershell” and it appeared that there might be a solution to my problem. However, I also realized I didn’t know anything about HTML so I signed up for a course with Edx University on HTML and CSS. That has turned out to be very useful.
In his book, Jones poses a problem: how can one collect different types of information about a computer and present it all in one single HTML document which can then be viewed in any browser? The native ConvertTo-HTML cmdlets can generate HTML for each extracted hunk of computer info, but can’t combine them into a single HTML file. (BTW, his new cmdlets also include JavaScript for interactive HTML features.)
It became evident I could concoct a Table of Contents that not only wasn’t overrun with extra “directory path” information, but also included borders, color, different font sizes and formats, etc. Something that would be more suitable for general consumption. (Think the wife…) I don’t need any JavaScript.
So back to my current cmdlet project… Instead of just collecting all files recursively from my archive for copying I now need to disassemble the folder/file tree structure so I can retain the parent directories for each block of files. I’m no longer interested in the files themselves, just the five pieces of information enumerated above. So the first chore is to get all the directories in the archive. Then go to each directory one at a time to see what’s inside. The If logic does that. Once a folder with archive-able files is located, I then need to sort those files by name and extension, select the last four pieces of information (name,type,size,date), stuff that into a single PSobject, and feed that to the -EnhancedHTMLFragment cmdlet. The fragment cmdlet produces a bunch of HTML, but not an entire document ready for a web page. One of the parameters for this fragment cmdlet should allow me to include a header that has the current directory path. So the table of info would have the four columns of info under the header directory… All good so far. Once each batch of files is created by feeding them to the -enhancedHTMLfragment cmdlet, it’s time to combine them all using the ConvertTo-enhancedHTML cmdlet. At the bottom of my "Make-NewTOC function, this would be the last line of code. One of the parameter inputs to this last cmdlet is a list of HTML Fragments. As you can imagine, these fragment names must be unique. This is the reason for the $i variable, and it does count the “file blocks.” The new-variable cmdlet allows me to create unique fragment names. I’m hoping I can easily figure out how to pass all the fragmenst to the final -enhancedHTML command, if I don’t know how many I have, but they still all have unique names…
So that’s where things stand. As I’ve said bits of code do work, and when I get the new function up and running, I can then play with the CSS (Cascading Style Sheet) and pretty the report up…