maxmustermann/PowerShell
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Grammar correction of Readme.md and other docs (#13269)

Browse source
This commit is contained in:
Tasnim Zotder 2020-07-29 22:53:09 +05:30 committed by GitHub
parent 6dec823077
commit 7f9b118dc0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
5 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
README.md
View file

@ -143,7 +143,7 @@ We have a Gitter Room which you can join below.
[![Join the chat](https://img.shields.io/static/v1.svg?label=chat&message=on%20gitter&color=informational&logo=gitter)](https://gitter.im/PowerShell/PowerShell?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
There is also the community driven PowerShell Virtual User Group, which you can join on:
There is also the community-driven PowerShell Virtual User Group, which you can join on:
* [Slack](https://aka.ms/psslack)
* [Discord](https://aka.ms/psdiscord)
@ -230,7 +230,7 @@ The telemetry we collect falls under the [Microsoft Privacy Statement](https://p
## Governance
Governance policy for PowerShell project is described [here][].
The governance policy for the PowerShell project is described [here][].
[here]: https://github.com/PowerShell/PowerShell/blob/master/docs/community/governance.md

8
docs/building/internals.md
View file

@ -19,7 +19,7 @@ We use dummy dependencies between projects to leverage `dotnet` build functional
For example, `src\powershell-win-core\powershell-win-core.csproj` has dependency on `Microsoft.PowerShell.Commands.Diagnostics.csproj`,
but in reality, there is no build dependency.
Dummy dependencies allows us to build just `$Top` folder, instead of building several folders.
Dummy dependencies allow us to build just `$Top` folder, instead of building several folders.
### Dummy dependencies rules
@ -106,7 +106,7 @@ On Linux/macOS, PowerShell Core depends on the binary `libpsl-native.so/libpsl-n
Building those native components requires setting up additional dependencies,
which could be a burden to those who don't seek to make changes to the native components.
At the meantime, the native component code seldom changes,
In the meantime, the native component code seldom changes,
so it doesn't make sense to always build them with `Start-PSBuild`.
Therefore, we decided to wrap the native components into NuGet packages,
so that we only need to build them once when changes are made,
@ -178,12 +178,12 @@ The layout of files should look like this:
Have the DLLs signed with `authenticode dual` certificate and run `nuget pack` from the parent of the `runtimes` folder where `psrp.windows.nuspec` resides.
Be sure to use the latest recommended version of [nuget.exe](https://www.nuget.org/downloads).
Publish latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/psrp.windows.
Publish the latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/psrp.windows.
`PowerShell.Core.Instrumentation.dll` NuGet package is created the same way, but in a separate directory following the same layout above.
To create a new NuGet package for `PowerShell.Core.Instrumentation.dll`, you will need the `PowerShell.Core.Instrumentation.nuspec` found in the repo under `src\PowerShell.Core.Instrumentation`.
Publish latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/PowerShell.Core.Instrumentation.
Publish the latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/PowerShell.Core.Instrumentation.
### libpsl

2
docs/building/linux.md
View file

@ -73,5 +73,5 @@ The `Start-PSBuild` script will output the location of the executable:
`./src/powershell-unix/bin/Debug/net5.0/linux-x64/publish/pwsh`.
You should now be running the PowerShell Core that you just built, if your run the above executable.
You should now be running the PowerShell Core that you just built, if you run the above executable.
You can run our cross-platform Pester tests with `Start-PSPester`, and our xUnit tests with `Start-PSxUnit`.

4
docs/building/windows-core.md
View file

@ -44,7 +44,7 @@ Or you can call `Install-Dotnet` directly:
Install-Dotnet
```
It removes the previously installed version of .NET CLI and install the version that PowerShell Core depends on.
It removes the previously installed version of .NET CLI and installs the version that PowerShell Core depends on.
If you have any problems installing `dotnet`, please see their [documentation][cli-docs].
[dotnet-cli]: https://github.com/dotnet/cli
@ -69,7 +69,7 @@ The function `Get-PSOutput` will return the path to the executable;
thus you can execute the development copy via `& (Get-PSOutput)`.
The `powershell` project is the .NET Core PowerShell host.
It is the top level project, so `dotnet build` transitively builds all its dependencies,
It is the top-level project, so `dotnet build` transitively builds all its dependencies,
and emits a `pwsh` executable.
The cross-platform host has built-in documentation via `--help`.

2
docs/cmdlet-example/command-line-simple-example.md
View file

@ -133,7 +133,7 @@ Creators Update. This version of the .NET Framework allows existing applications
However, for Windows systems that have not been updated to .NET Framework 4.7.1 such a
binary module will not run correctly in Windows PowerShell.
Let's see what happens when you attempt use this module in **Windows PowerShell** on
Let's see what happens when you attempt to use this module in **Windows PowerShell** on
Windows 10 CU (1703 or lower) without .NET Framework 4.7.1 installed.
1. Copy `MyModule.dll` to a folder on a Windows machine.