generating passwords sometimes misbehaves since updating to macOS Sierra

[maxjacobson]

(The macOS Sierra thing may or may not be related, but that's the one thing that's changed recently on my setup)

RUST_BACKTRACE=1 rooster generate tessssssst maxjacobson
Type your master password: 
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', ../src/libcore/result.rs:788
stack backtrace:
   1:        0x103b78deb - std::sys::backtrace::tracing::imp::write::h29f5fdb9fc0a7395
   2:        0x103b7ae3a - std::panicking::default_hook::_{{closure}}::h2cc84f0378700526
   3:        0x103b79fd8 - std::panicking::default_hook::hbbe7fa36a995aca0
   4:        0x103b7a618 - std::panicking::rust_panic_with_hook::h105c3d42fcd2fb5e
   5:        0x103b7a476 - std::panicking::begin_panic::hbf62ea4a5ff3f9de
   6:        0x103b7a388 - std::panicking::begin_panic_fmt::h20f5943904e5791d
   7:        0x103b7a2df - rust_begin_unwind
   8:        0x103ba0560 - core::panicking::panic_fmt::h19323e466869c656
   9:        0x103b733c5 - core::result::unwrap_failed::hbc58bb4cc0bc5dd4
  10:        0x103b737d2 - rooster_clipboard::main::hc48126e8c5f27f80
  11:        0x103b7a29d - std::panicking::try::call::h5df3ac2979db3c90
  12:        0x103b7b15b - __rust_try
  13:        0x103b7b015 - __rust_maybe_catch_panic
  14:        0x103b79951 - std::rt::lang_start::hfe9ab243c60ffb9b
Alright! Here is your password: KSt0pp032B3E@\+;-\;i>9.GK{5G6XeH

It doesn't totally fail, but it is unexpected that it displays the password rather than copying it to my clipboard.

I think something in the clipboard code isn't compatible with macOS Sierra, maybe?

[maxjacobson]

More problematically, it doesn't save the new password to the list of passwords.

[maxjacobson]

Hmm.... sometimes it works, other times it doesn't. It seems like it fails within tmux and succeeds outside of tmux... does that sound plausible?

[maxjacobson]

Ah.. this is a tmux thing.. this fixed the issue for me: tmux/tmux#543 (comment)

[conradkleinespel]

@maxjacobson Hey ! Sorry about the issues, but glad you found a solution ! 👍

[maxjacobson]

heh thanks 😅. I closed the issue because I found that work-around, but I wonder if there isn't another issue hiding in that experience stated differently as "if copying to the clipboard fails, the newly-generated password should still persist"

[conradkleinespel]

@maxjacobson It's true that the current implementation can fail saving a new password if copying to the clipboard fails. This is because currently, when the copy fails, then we return early. See here:
https://github.com/conradkleinespel/rooster/blob/master/src/commands/generate.rs#L79
and here:
https://github.com/conradkleinespel/rooster/blob/master/src/main-rooster.rs#L162

Consequently, the following line store.sync(file) does not run and the new password is lost. Changing this so that a failed copy does not lose the password makes sense ! I believe changing the return Err(1) to return Ok(()) in the command would be an easy enough fix.

If you make a PR that fixes this, I'm glad to merge. Let me know if you want to work on this ! 😃