Alternatives to using eval in bash

tyler_adams

As a bash user, I find myself uncomfortable using eval on a strange command. Instead, I find myself using alias in my .bashrc as such
alias ops='export OP_SESSION_TEAM="$(op signin TEAM --output=raw)"'

where TEAM is my actual team's name. However, this has a serious drawback where if I try to Ctrl-C, my terminal becomes all messed up.

Does anybody have any other ways they use to securely set bash variables? Thank you.

I'm using op CLI v .2

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

jpgoldberg

As a bash user, I find myself uncomfortable using eval on a strange command.

You aren't the only one concerned about this. And your alias is a good alternative for those who wish to create aliases.

As you know, the problem we are trying to solve is how we allow one process to authenticate and set up a session, op signin, that can be used by processes launched independently. Roughly, there were two ways to approach this. An environmental variable holding on to a session secret (which is what we've done) or something like gpg-agent or ssh-agent, which hold the secret and tried to limit use of the secret to clients it authenticates locally. Neither of those approaches are without their draw-backs. So we went with the one that was easiest to implement. (OK, that isn't the only reason, but when you have two less-than-ideal solutions, it does play a role.)

A third option was to build our own op-shell, so that the various op commands would be processes that aren't launched independently of each other. But that would still pose barriers for people trying to script things in the ways that they need to.

However, this has a serious drawback where if I try to Ctrl-C, my terminal becomes all messed up.

I'm not entirely sure what what combination of circumstances are leading to that for you. Are you working on a console or ssh-ing in to your environment? You might be able to use something like screen(1) to give you a distinct shell in which you use op. On windowing systems, you can just open up a dedicated {i,x}term (or Terminal.app) window.

tyler_adams

Yeah, I concur that the environment variable is the best solution.

For the Ctrl-C issue, I'm locally using iterm2 + tmux + bash. The behavior is reproducible with iterm2 + bash. It is not reproducible on iterm2 + fish. For an example of how things get messed up, if I keep pressing enter, I see
~ $ ~ $ ~ $ ~ $ ~ $ ~ $ ~ $ ~ $
all on a single line. I also cannot see any other characters I type.

The way to restore the terminal to usage is
stty sane
but having a messed up terminal is still unideal.

rickfillion

For sure. I wonder what’s going on there.

jpgoldberg

Being able to type "stty sane" blind is one of the first things one must learn. Like learning how to exit vi.

MrC

Try reset, or create an alias.

The issue you see can be reproduced in bash using several methods - its a problem that's been around for a long time. I used to get it routinely (but don't recall the exact circumstances now - I believe it was w/vim editing a file on a Windows file server when there was problems closing the file).

rickfillion

Thanks MrC.

Rick