Three tabs and the scope of translation
Bash and PowerShell have different names, arguments, and data formats even for commands with similar purposes. This page features three tabs: Script Translation, Command Correspondence Table, and Grammar Comparison Guide.
These serve distinct purposes: partially replacing commands, looking up examples by operation name, and comparing syntax side-by-side.
Choosing the tab based on what you want to check prevents confusing the examples in the correspondence table with the scope of the automatic translation.
In the script translation tab, pasting Bash or PowerShell text into the input field displays candidates replaced with the other format in the output field.
The conversion mechanism is string replacement applying ordered regular expressions. It does not build an abstract syntax tree to understand the whole script's meaning, nor does it execute commands.
You can try prepared inputs with the sample button, erase them with clear, and copy the needed results. The output is a draft to start rewriting, not a fully runnable finished product.
This difference becomes more critical for longer scripts. Even if a single-line command name seems correct, actual behavior changes depending on surrounding variable expansions, pipes, redirects, and quotes.
First, check conversion candidates with short single lines, and then review them within their context. The code in the input field is treated as a string within the page; there is no feature to read files or launch a terminal.
Replacement examples from Bash to PowerShell
When the translation direction is Bash to PowerShell, rules are applied to certain formats like export, mkdir, rm, cp, mv, cat, grep, pwd, find, curl, echo, and touch.
For example, mkdir -p logs is replaced with New-Item -ItemType Directory -Path logs -Force, and export NAME="value" becomes $env:NAME = "value".
Viewing the output format via the screen samples first, then inputting your own short commands makes it easier to confirm which words change and which arguments remain.
This process does not transfer all argument meanings. In the echo "Init log file" >> path example, only the echo part changes to Write-Output, and >> path remains as is.
Since there is no feature to verify the character encoding, line breaks, or destination file state when appending, you must separately confirm if the intended outcome occurs in the target PowerShell environment.
Also, note that touch and New-Item -ItemType File -Force are not truly equivalent; Microsoft's official examples warn that this PowerShell command overwrites existing content to a length of 0.
For deletion operations, rm -rf [path] is replaced with Remove-Item -Recurse -Force -Path [path]. The bracketed [path] here is an explanatory symbol, not a value to run directly.
The user must determine which environment the entered path points to, and whether recursive or force options are needed. It is crucial to develop the habit of checking the target before copying when a deletion command appears in the conversion results.
Reverse direction to Bash and unconverted parts
Switching the translation direction in the center of the screen changes the rules to PowerShell to Bash, and deletes both the input and output fields.
If you want to keep the previous result, save it elsewhere before switching. The reverse direction also only replaces specific command formats.
For example, it displays candidates corresponding to New-Item -ItemType Directory -Path logs -Force as mkdir -p logs, and Get-Content -Path notes.txt as cat notes.txt.
This does not guarantee that the exact same file can be referenced in a Bash environment.
If no rule matches part of the input, that section remains as the original string in the output. Consider this a possibility that no replacement rule was found for this part, rather than a sign of successful conversion.
Specifically, there is no feature to automatically rewrite grouped structures like if, for, or function definitions, nor text processing using awk or sed, into equivalent syntax.
Even if some command names change on the surface, PowerShell-specific syntax may remain before and after them.
The regular expressions do not perfectly understand whether a string is inside a comment or quotes. If a word resembling a target command appears in explanatory text and matches a rule's format, unintended parts may change.
Conversely, replacements might fail if paths contain spaces, argument orders differ, or aliases are used. Compare the results line by line with the input to look for remaining original text and unexpected replacements.
Using the 18-command correspondence table
The Command Correspondence Table is a quick reference for 18 static examples covering file operations, networks, systems, and processes.
Entering an operation name or a command name like grep or Get-Content into the search field filters the candidates. In the selected row, you can read the Bash and PowerShell examples side-by-side and copy them individually.
This is useful when you know what you want to do but cannot recall the other shell's name.
However, the correspondence table and the translation tab do not share the same dictionary; the converter does not cover all commands in the table.
While the table includes ls -la and Get-ChildItem -Force, connectivity checks using ping and Test-Connection, or PID specifications with kill and Stop-Process, commands like ls, ping, and kill are not included in the translation tab's replacement rules.
Do not assume entering them in the translation field will automatically replace them just because they are in the table.
For example, grep and Select-String are listed together for searching strings, but their return values and subsequent processing methods are not the same.
The table also shows a header retrieval example with curl -I (which is a HEAD request), but the provided PowerShell equivalent using Invoke-WebRequest defaults to a GET request; it is not equivalent to HEAD.
Verify not only the command names but also the return values and what to use in the next pipeline stage before utilizing them.
Considering manual porting with the grammar guide
The Grammar Comparison Guide is static reference material showing variable definitions, references, if conditional branches, for loops, function definitions, and comparison operators across 6 pairs.
In Bash, you assign with VAR="value" and reference with $VAR. In PowerShell, you add a dollar sign to the variable name like $Var = "value".
Note that static examples using single quotes like Value:$Var do not interpolate variables; carefully distinguish the example's comments from its text.
Comparing the two sides of the guide helps discover areas where simply changing the command name is insufficient.
In the control examples, while Bash uses if and fi, for and done, PowerShell uses parentheses, curly braces, and comparison operators.
How function arguments are received also differs. This page does not automatically apply the guide's examples to the script you enter.
You must manually consider whether the actual conditional expression is a numeric or string comparison, and how to handle empty variable values.
Simply pasting the grammar examples will not faithfully reproduce the original conditional branch.
Standard Bash pipes between commands mainly pass text, whereas PowerShell cmdlets pass objects with properties. Even if the translation tab partially replaces grep in a pipe, it does not port the data type or processing logic of the entire pipeline.
Aligning with PowerShell may require inspecting properties and rebuilding the process. Use the guide as a starting point to consider these differences, and separately verify output equivalence in the execution environment.
Pre-use checks for generated results
Before using the copied results in an actual terminal, first check the operation target paths, second the options, third the quotes and variable expansions, and fourth the current directory and execution permissions.
Specifically, minor string differences in deletions like rm or Remove-Item, moves like mv or Move-Item, or network calls like curl or Invoke-WebRequest can lead to operating on entirely different targets.
The converter cannot guarantee conversion results are correct or safe executable commands; verify the displayed candidates in a safe virtual environment before directly incorporating them.
The page itself does not execute code.
The secret-xyz in the samples is a string for explanation. You do not need to enter actual tokens or passwords directly. While the conversion calculation is done in the browser's JavaScript and lacks a file upload feature, this alone does not guarantee zero overall site communication, complete offline functionality, or immediate erasure of inputs and clipboards.
When checking scripts containing confidential values, replace those values with dummy strings first.
If known commands remain in the conversion result, look up their names in the correspondence table; if if or functions remain, consult the grammar comparison guide.
The proper usage is to then check the official shell documentation and execution environment specifications, manually rewriting only the necessary parts.
By combining these three tabs as aids for candidate creation, reference, and learning rather than automatic generation of completed code, you make it harder to overlook incorrect porting.