Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's document: PowerShell #6621

Closed
reinhart1010 opened this issue Oct 1, 2021 · 12 comments
Closed

Let's document: PowerShell #6621

reinhart1010 opened this issue Oct 1, 2021 · 12 comments
Labels
decision A (possibly breaking) decision regarding tldr-pages content, structure, infrastructure, etc. new command Issues requesting creation of a new page or PRs adding a new page for a command.

Comments

@reinhart1010
Copy link
Collaborator

reinhart1010 commented Oct 1, 2021

Sorry for the bad timing (it's the first day of Hacktoberfest 2021 so yeah), but I think documenting tldr pages for the Windows cross-platform PowerShell could be a great idea.

No, not the tldr page for windows/powershell, but all the PowerShell cmdlets like Get-Help, Invoke-WebRequest, Get-StartApps and so on.

These cmdlets uses a combination of kebab-case and (Upper) CamelCase, while according to the tldr-page guidelines all commands should be lowercase. So this could be a concern for contributors and clients.

Furthermore, some PowerShell cmdlets are only available for Windows, making the page structure slightly complicated. For example, curl often redirects to Invoke-WebRequest when used in Windows where the actual curl is not installed. Note that both curl and Invoke-WebRequest are completely different commands with different parameters and options.

@reinhart1010
Copy link
Collaborator Author

Okay, I've seen that the Get-Content PowerShell command is also documented in windows/get-content, and the command also works in my Linux installation of PowerShell, too!

image

@navarroaxel navarroaxel changed the title let's document: PowerShell Let's document: PowerShell Oct 1, 2021
@sbrl
Copy link
Member

sbrl commented Oct 1, 2021

Hey there! Thanks for opening this issue. Hmm, I think we want a few opinions on this.

It would be easy if powershell was windows-specific (though I can imagine Windows accounts for the majority of powershell usage anyway), but as you say powershell is cross-platform.

Perhaps documenting in common would work - so long as any commands documented are clearly labelled as powershell commands rather then ordinary commands that work in a regular shell.

Let's wait for some more opinions from people on this before making a decision.

@marchersimon
Copy link
Collaborator

We probably won't have any name collisions, but even though it's available on all platforms it will be used on Windows most of the time. Not directly comparable, but still: we also don't put Linux commands under common because it's available through WSL.

@pixelcmtd pixelcmtd added the new command Issues requesting creation of a new page or PRs adding a new page for a command. label Oct 3, 2021
@reinhart1010
Copy link
Collaborator Author

I was thinking to simply put all PowerShell documentation into powershell/, and some Windows-only commands will have this notice:

This command works only on Windows

or (Windows Server-specific)

This command works only on Windows Server

@marchersimon
Copy link
Collaborator

I don't think we should really add a new platform for PowerShell. I think putting all PowerShell pages into windows/ makes the most sense.

@sbrl
Copy link
Member

sbrl commented Oct 5, 2021

Yeah, I agree @marchersimon. The windows platform makes the most sense here.

@sbrl
Copy link
Member

sbrl commented Dec 7, 2021

Ref "This command works only on Windows", I would suggest that the better solution here would be a platform-specific copy of the page in the respective platform folder. For example, if blah has some common functionality but also some windows-specific functionality, then we would have copies of the page under common/blah and windows/blah, with the Windows-specific functionality being documented under windows/blah only.

@tayopi
Copy link

tayopi commented Sep 28, 2023

I'd love to help with this since PowerShell is my primary shell. I had a question about documentation though. For commandlets like Get-ChildItem, there are built in aliases (e.g. dir, gci, ls) These were included by Microsoft to make life easier for users who are more familiar with shells like Command Prompt on Windows or bash. I think these are helpful, but I don't know the best way to document them or if they should be documented at all.

@reinhart1010
Copy link
Collaborator Author

There is a standard template for writing alias documentation, see https://github.com/tldr-pages/tldr/blob/main/contributing-guides/translation-templates/alias-pages.md. But there are some edge cases like Invoke-WebRequest with curl and wget, like on #8177.

For Command Prompt aliases in PowerShell, as long as the PowerShell version accepts the traditional Command Prompt parameters, I think it’s OK to add something like:

In PowerShell, this command is an alias of {{PowerShell-Command}} which also supports the following Command Prompt (cmd.exe) commands.

@kbdharun kbdharun added the let's document Tracker issue to document multiple subcommands/commands of a tool or utility or category. label Oct 21, 2023
@sbrl
Copy link
Member

sbrl commented Nov 29, 2023

#11227 has implemented the issues discussed here. However, it seems that #11298 has put PowerShell commands in the wrong place (common/ instead of windows/), unless I'm confused?

/cc @kbdharun, @sebastiaanspeck?

@kbdharun
Copy link
Member

#11227 has implemented the issues discussed here. However, it seems that #11298 has put PowerShell commands in the wrong place (common/ instead of windows/), unless I'm confused?

/cc @kbdharun, @sebastiaanspeck?

It's intentional I think, some powershell commands are cross platform, whereas most are Windows specific.

@sbrl
Copy link
Member

sbrl commented Nov 29, 2023

Ahhh okayt @kbdharun. Thanks for the clarification. So long as PowerShell commands are clearly labelled, I see no issue with this. In which case, I'm going to close this issue for now given we've all agreed.

I'd suggest that any lists of PowerShell commands to document should be a separate issue to keep them clean.

We can always re-open if there's more to discuss.

@sbrl sbrl closed this as completed Nov 29, 2023
@sbrl sbrl added decision A (possibly breaking) decision regarding tldr-pages content, structure, infrastructure, etc. and removed let's document Tracker issue to document multiple subcommands/commands of a tool or utility or category. help wanted You can help make tldr-pages better! labels Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
decision A (possibly breaking) decision regarding tldr-pages content, structure, infrastructure, etc. new command Issues requesting creation of a new page or PRs adding a new page for a command.
Projects
None yet
Development

No branches or pull requests

7 participants