PowerShell: Enough with the text files already

A note to all PowerShell enthusiast, PowerShell has made it, it’s on the map… A significant portion of that success is due to the power of the pipeline. It’s ability to act as the glue for any task.  Unfortunately, the  skill level required to implement this glue depends on the echo-system.  As a PowerShell enthusiast you are a member of this echo-system, and any code you write either helps or hurts this effort.  In short when posting code to the world show them what well written code looks like!  Writing a function that is hard set to read a list of servers from a text file is NOT good code!   Personally I think this should throw an error.

Okay so I don’t approve of reading from a text file, so what’s my solution?  Remove that part of the logic entirely!  There are literally hundreds (perhaps thousands) of techniques that could be used to retrieve data for any given operation.  leave the getting to the end user.  If you must get the data then show a more practical approach.  Seriously,  it’s Windows PowerShell after all, that list of computers… chances are they’re all running windows… and there is a high probability that they belong to a domain! In your examples highlight extracting the data from AD.  After all would you really use static data in one of your scripts?

If you just can’t use the quest cmdlets use ADSI anything but a text file. Another one of my favorites is importing a list of IP Addresses.  I know it’s incredibly easy to create a list of IP Addresses in Excel, but is that really the lesson?  Hey PowerShell is the most important thing since the mouse, but if you need 254 concurrently numbered IP’s get Excel…  just add the code

Even better highlight why it’s so important to always emit object.  Show the benefit of such an approach.

I know, I know it’s all been done before.  I know we already had the why you should emit object discussion, and the foreach construct vs foreach-object cmdlet debate, etc… believe it or not the community has grown ten fold since those discussion’s where closed.  While I don’t want to constantly rehash this stuff… I’m asking that we don’t perpetuate the problem by using BAD techniques when we know better.

If you don’t have time just omit it.   Hide that part from the point of the post.  There is nothing wrong with

After all the do-something is the important part!  Just leave populating $servers to someone else… Why does this matter?  Simple, you never know what someone will learn from your code.  I read PowerShell post all the time, and I am constantly learning something new.  Just not always what the author intended.  The point of post x was to teach me how to use widget x from PowerShell.  Only I found this $? thing (what is that, and what does it do?)…   The next guy finds the same post via google because there trying to figure out the foreach construct, and bamn that get-content server.txt just became part of his repertoire.  Chances are he never even got to the part for widget x.  Moral of the story it’s better to omit part of the solution then to publish a poor answer.

Another penalty imposed by this hard coded methodology is it totally breaks the has-a model PowerShell was built around.  requiring a text file with a list of server names is the text book definition of the is-a model.  lamen terms by hard coding such a critical portion of your code… by importing data from a file you limit the flexibility of  your code.

It’s not all bad though, a couple years ago there where 10 guys.  Ten people who taught all of us how to use PowerShell.  Today there are 10 new PowerShell bloggers every day, and it appears that every team in Redmond (except SCCM) has PowerShell on it’s road map. I’m not trying to be the code police, but can we at least loose the text files?

~Glenn

1 thought on “PowerShell: Enough with the text files already”

  1. You go Glenn!
    I totally agree with your stance. By breaking that dependency you keep things flexible and when something in your script does go wonky, you have one fewer dependency to check.

    Reply

Leave a Reply