assumes stty is exactly at /bin/stty

[coreyoconnor]

stty is not at /bin/stty on all unix platforms. For instance, on NixOS, stty is at /run/current-system/sw/bin/stty.

On NixOS use of speakeasy results in:

failed turning off console echo for password entry:
        no such file or directory

which is to be expected as /bin/stty does not exist.

[bgentry]

@coreyoconnor is there a reliable way to fix this for all platforms?

[coreyoconnor]

Any particular reason an absolute path is used? What about relying on PATH to contain the stty executable?

[bgentry]

@coreyoconnor not sure, I didn't write the original platform-specific code. We might need somebody to try alternatives on a couple of platforms, I'm not actively using this code so not able to help there.

[coreyoconnor]

I understand :-)

I'm not familiar with Go at all. The change might be as easy as replacing "/bin/stty" with "stty". However, I haven't figured out how to build a modified go package/lib so not really sure.

[fiksn]

I have exactly the same problem on NixOS. Speakeasy is a transitive dependency of etcdctl (https://github.com/etcd-io/etcd/tree/master/etcdctl). User manipulation fails with:

Password of user: Error: failed to ask password: failed turning off console echo for password entry: no such file or directory.

[aerth]

the hardcoded path to the stty binary can be an exported variable (that can be changed via linker -X flag or from main package speakeasy.Path or something (changed at build time). This, or use the user's PATH. (changes during runtime)

until this is fixed, theres a few entire communities of (linux) operating system users that can't use any programs that rely on speakeasy

so to fix its either export the var or lookup with PATH

thanks

[cameronfyfe]

Any updates on this? Any blockers for merging #24 to resolve this? This is currently blocking me on some workflows due to some projects that use this dependency, so willing to help test if PR needs some more testing before being merged.

[bgentry]

PRs welcome! I would imagine this working with the hardcoded path becoming a function that can either check the PATH for an stty or else some type of global setting (since this can realistically only have one value during a program's execution on a given platform).

[coreyoconnor]

What about delegating to $SHELL -c exec stty ... ? That would, afaik, use the shell to resolve stty. Or is there reason to prefer a setting?

[cameronfyfe]

Sorry, I meant to link to the existing PR #24 above but realized I just linked to this issue instead.

I'm not a Go developer but the approach in this PR using https://pkg.go.dev/os/exec#LookPath looks good to me.