3 ms·
OP here. The open-sourcing and cross-platformizing of powershell itself makes it about 99% free to create "cross-platform" projects. A few specifics I came acro
by latkin 10y ago
OP here. The open-sourcing and cross-platformizing of powershell itself makes it about 99% free to create "cross-platform" projects. A few specifics I came across from the remaining 1%:
- Use platform-appropriate native tools (e.g. clip.exe/pbcopy/xclip as mentioned)
- Use appropriate path separators (tip: just use / always - Windows handles it fine)
- Be mindful of case-sensitive file paths
- Use platform-appropriate newline (fixed a bug here just this morning)
- Avoid BOMs when writing files, unix doesn't like them (use [IO.File]::WriteAllText, not Out-File. Sad.)
- Need to restrict yourself to powershell cmdlets and .NET APIs that are available in the open-source version of powershell
- ygra 10y agoDidn't clip have trouble with Unicode? There should be Set-Clipboard now, too (unless I got that from pscx or similar).
- latkin 10y agoThanks for the heads up, I didn't know about unicode problems in clip.exe. Do you have a link? Set-Clipboard exists in full Windows Powershell, but not in Powershell "core" (open source version). I also didn't find a clipboard API in the current .NET core. So I went with native tools for now, and clip.exe is the only built-in option for Windows. If/when there is better xplat clipboard support in .NET or Powershell core I'll definitely move to that. Another option would be to check if Set-Clipboard exists and use it if so.
- ygra 10y agoSorry, it's not clip that has problems with Unicode, but rather PowerShell when piping to native commands. I should have remembered that fact. One can set $OutputEncoding to UTF16LE to make things work. In that case, clip has no problems with Unicode, but by default PowerShell will use CP1252 when piping data to native programs. Maybe the variable can be set differently only for your module.