Bash and PowerShell side by side¶

Practical 5.2 bash-and-powershell-side-by-side-annex.pdf · PDF

You talk to your grandmother in Catalan and to your English teacher in English. You never stop to ask "which language is better?". You ask "who am I talking to?". You are already bilingual.

A sysadmin is bilingual too. Linux servers speak Bash. Windows machines speak PowerShell. In a real company you meet both on the same day, often in the same hour. Today you say the same ten sentences in both languages — and you discover that the two shells do not just use different words: they think differently.

Two languages, one job¶

In Back to the shell you rebuilt Bash: redirection, pipes, variables, globbing. In PowerShell first contact you met PowerShell: cmdlets named Verb-Noun, Get-Help, Get-Member, and a pipe that carries objects.

Today is translation. Keep the bilingual idea in mind all page: same meaning, different words, and sometimes a different grammar.

The dictionary¶

Look for patterns before you memorise anything:

• Bash names are short and must be memorised. PowerShell names are long and can be guessed: if Get-Content reads a file, Set-Content probably writes one.
• Both use |, $x and double quotes in the same way.
• Assigning a variable is different: Bash wants no spaces and no $ (x=5). PowerShell wants the $ and allows spaces ($x = 5).

A worked example¶

"Show the first three lines of staff.csv."

Bash         head -3 staff.csv
PowerShell   Get-Content staff.csv -TotalCount 3

Same three lines on both screens. How would you have found -TotalCount? Not by knowing it: Get-Help Get-Content, read the list of parameters, and there it is. That is the method.

The traps of translation¶

Every bilingual person knows false friends: words that look the same but mean something else. The shells have them too.

Text or objects: the real difference¶

Here is where the two languages stop being a matter of vocabulary. Take one question: how many people are in each department?

The file staff.csv (from Back to the shell) starts like this:

user,dept,role,year
marta,dev,backend,2019
joan,design,ui,2020

tail -n +2 staff.csv | cut -d, -f2 | sort | uniq -c

      2 admin
      3 design
      7 dev

Import-Csv staff.csv | Group-Object dept | Select-Object Name, Count

Name   Count
----   -----
dev        7
design     3
admin      2

flowchart LR
    subgraph BASH ["Bash: the pipe carries text"]
        direction LR
        B1["<b>tail</b><br>lines of characters"] -->|"text"| B2["<b>cut -f2</b><br>column by position"]
        B2 -->|"text"| B3["<b>sort + uniq -c</b><br>count neighbours"]
    end
    subgraph PS ["PowerShell: the pipe carries objects"]
        direction LR
        P1["<b>Import-Csv</b><br>one object per line"] -->|"objects"| P2["<b>Group-Object dept</b><br>property by name"]
        P2 -->|"objects"| P3["<b>Select-Object</b><br>Name, Count"]
    end

Now imagine a colleague adds a new first column to staff.csv, say an employee number. What breaks?

• In Bash, -f2 now points at the wrong column. You get a wrong answer, and no error at all.
• In PowerShell, dept is still called dept. The command keeps working.

That is the real advantage of objects: a name survives changes that break a position.

So does PowerShell win? No. Bash works on any text at all: logs, configuration files, the output of a program written forty years ago. Nobody has to turn it into objects first.

Linux keeps its configuration in text files, so its shell is good with text. Windows keeps it behind programming interfaces, so its shell is good with objects. Each shell looks like its system.

Variables inside strings¶

The last task of the practical writes a small report file with today's date and a count. Both shells put a command's output in a variable with $( ), and both replace variables inside double quotes.

today=$(date +%F)
n=$(tail -n +2 staff.csv | wc -l)
echo "Report $today: $n people" > report-$today.txt

$today = Get-Date -Format yyyy-MM-dd
$n = (Import-Csv staff.csv).Count
"Report ${today}: $n people" | Set-Content "report-$today.txt"

The file contains a line like Report 2027-01-12: 12 people.

Look at the braces in ${today}. In PowerShell, $today: followed by text is read as a drive name (like C:), and the line fails. The braces mark exactly where the variable name ends. In Bash the colon is harmless.

To prove a folder is gone after deleting it, Bash just lists (ls); PowerShell can ask directly with Test-Path tramuntana, which answers True or False.

Practical 5.2¶

Open the Practical 5.2 sheet (the button at the top). You need deb-lab and win11 running at the same time, and staff.csv in a folder p41 in your home in both machines.

The ten tasks go from easy (where am I, create folders) to the ones where text and objects really differ (count per department, sort by year, list the processes using most memory). For each task, write in your Markdown report practical-5.2-surname.md:

• the Bash command and the PowerShell command, each in a code block;
• the output, pasted as text (not a screenshot of the whole desktop).

Finish with 4–6 lines of reflection: which shell for which job, with one example from the practical. The report goes on Google Classroom.

Key takeaways¶

• Bash and PowerShell do the same everyday jobs with different words: a dictionary plus man / Get-Help is all you need to translate.
• Bash names are short and memorised; PowerShell cmdlets are long Verb-Noun names you can guess.
• Watch the false friends: grep is case-sensitive and Select-String is not; > redirects in both shells; Rename-Item wants a name, not a path.
• The Bash pipe carries text; the PowerShell pipe carries objects with named properties.
• A column position (cut -f2) breaks silently when the file changes; a property name (dept) does not.
• Neither shell is better: each one looks like its system — text files on Linux, programming interfaces on Windows.

Quick check¶

Next: you already know the people behind the Linux prompt. Now create them on Windows, with the GUI and with PowerShell, in Users and groups on Windows.