Technical Review: Learn PowerShell in a Month of Lunches, Fourth Edition

Let me continue with a series of blog posts discussing technical reviews conducted between 2022 and the present year. In a previous post, I highlighted “Learn PowerShell in a Month of Lunches” as the ideal starting point for anyone delving into PowerShell.

If you’ve never read any book from the “Learn <Something> in a Month of Lunches” series, these books are unique because each chapter contains clear explanations, examples, and practical lab tasks at the end to reinforce the chapter’s topic. Such books are designed to streamline your learning process. As evident from the table of contents, there are approximately 30 chapters or fewer. By dedicating just one day to each chapter, you can master the technology in just one month.

Having reviewed this book myself, I found it immensely valuable. The authors, PowerShell team members Travis Plunk and Tyler Leonhardt, alongside Microsoft MVP James Petty, have updated the third edition to encompass the latest version of PowerShell, which includes its expansion into multiple platforms such as Linux and macOS. Consequently, the book is no longer confined to Windows.

Let’s examine the table of contents to see what you’ll be able to accomplish with PowerShell after reading the book.

:: Table of Contents ::

1 Before you begin
2 Meet PowerShell
3 Using the help system
4 Running commands
5 Working with providers
6 The pipeline: Connecting commands
7 Adding commands
8 Objects: Data by another name
9 A practical interlude
10 The pipeline, deeper
11 Formatting: And why it’s done on the right
12 Filtering and comparisons
13 Remote control: One-to-one and one-to-many
14 Multitasking with background jobs
15 Working with many objects, one at a time
16 Variables: A place to store your stuff
17 Input and output
18 Sessions: Remote control with less work
19 You call this scripting?
20 Improving your parameterized script
21 Using regular expressions to parse text files
22 Using someone else’s script
23 Adding logic and loops
24 Handling errors
25 Debugging techniques
26 Tips, tricks, and techniques
27 Never the end
App. PowerShell cheat sheet

Is this book for you? If you’re an Administrator, DevOps Engineer, or even a developer, you’ll undoubtedly find the book extremely useful and easy to follow. It covers topics such as handling errors, loops, filtering and comparison, input and output, and much more. After reading at least two editions myself, I highly recommend this book as one of my favorites, given its well-structured content (chapter-labs-summary). Rating 10/10.

Git: clone succeeded, but checkout failed

Have you ever faced any issues with git clone? Personally, I can’t recall any significant or memorable problems I’ve encountered while cloning remote repositories. Typically, the issues were related to authentication or network connectivity. Therefore, there was nothing particularly special to write about. However, as you work with different environments, the chances of coming across something interesting enough to share increase, even though it might be obvious to some.

Let’s take a simple example: you’re trying to clone an existing repository, which was created by someone else. The repository had already been filled out with files you need. Assuming you have credentials in place, you run git clone <repo’s url> on your Windows machine and get the following:

I hid the error message. I’ll reveal it later

What could go wrong? The cloning process succeeded, indicating that the issue is not related to Git credentials or network connectivity. However, the checkout process failed. What does this mean? It means that if you navigate to the folder of the cloned repository in the explorer, you won’t find any files written to the disk. Now, let me reveal the full error message, which is straightforward:

error: invalid path 'config/app1/application-staging.yml '
fatal: unable to checkout working tree

Found a “root cause”? There is the whitespace at the end of the filename.

However, you may wonder, since the repository was pre-created and used by other people, how did this happen? You’re correct to question that.

The reason is that Windows doesn’t support trailing space characters and automatically removes them when saving a file (you can read more about it here). On the other hand, Linux does support both leading and trailing whitespaces in filenames.

“file1.txt” and “file1.txt ” are two different files actually

Git knows about these limitations and has a special config setting to control it:

core.protectNTFS

If set to true, do not allow checkout of paths that would cause problems with the NTFS filesystem, e.g. conflict with 8.3 “short” names. Defaults to true on Windows, and false elsewhere.

The reason why other people can clone the repo without issues is that core.protectNTFS is set to false (manually or because of underlying OS)

So, to clone the repo on Windows you can use the following command:

get clone -c core.protectNTFS=false <repo url>
and now you can fix the wrong filename and sync with remote repo

As a summary, I would advise all developers and DevOps engineers to strictly avoid using trailing or leading spaces in filenames altogether. By doing so, we can eliminate the potential conflicts and issues that may arise from incompatible behaviors between different operating systems.