
Show HN: 1Poshword, cross-platform PowerShell client for 1Password - latkin
https://github.com/latkin/1poshword
======
Analemma_
This is awesome! Props for going the extra mile and including things that
people who doing quick bash-to-PowerShell ports tend to leave out- like
pipeline input and SecureString. Here is the rare "Show HN" thing that I'm
going to start using right away.

------
huhtenberg
> 1Poshword

To be pronounced in Sean Connery's voice... though that'd be more like
1Pashword.

~~~
s_kilk
His name's Sawn, stop making fun of his speech impediment. /s

------
daenney
It's amazing how things change, sometimes so fast. PowerShell and not just
cross-platform but open source too. Two-year ago me would've assumed this was
an oddly timed April fool's joke.

------
pacuna
this is super cool. One big struggle I had transitioning from OS X to Linux
was 1password. I ended up using wine with the windows version which was
awkward. I love CLI's to this may be a nice solution. Thanks!

------
spraak
I don't see how this works on Linux though?

~~~
MandieD
Linux has had PowerShell support for a few weeks now, and if you look in the
lib.ps1, you'll see that ClipboardCopy function tries clip.exe (Windows), then
pbcopy (MacOS), then finally xclip (Linux).

The module author used good form in dividing things up between the functions
(cmdlets) that user should call from the PowerShell commandline and shouldn't
change (1Poshword.psm1) and helper functions whose names are subject to change
if he ever rewrites something (lib.ps1).

~~~
latkin
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
Didn't clip have trouble with Unicode? There should be Set-Clipboard now, too
(unless I got that from pscx or similar).

~~~
latkin
Thanks 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
Sorry, 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.

------
sidneys
lincoln@ecorp.com fs0ciety

awesome

