Respect $TR_AUTH like cli tool transmission-remote

[doronbehar]

The official tool by the transmission team, transmission-remote, accepts an option -ne (or --authenv) which reads $TR_AUTH and gets authentication info from this environmental variable.
Could it be implemented in stig? That will enable me to remove the wrapper script I have in my dotfiles repository.

[rndusr]

Sure, shouldn't be a problem. But I would implement it as a setting, not as a CLI option. So you would have `set srv.authenv true` or something similar in your config file.

[doronbehar]

Sounds great, even better than what official transmission-remote offers :)

[rndusr]

@doronbehar, I currently don't see the real benefit of reading $TR_AUTH. Why
don't put set srv.url user:password@host:port in your rc file?

[doronbehar]

Well first of all, I think that having a password in plain text in a configuration file is a bad habit.

The way I set $TR_AUTH in my shell configuration files for transmission-remote is using pass just like this. I think it's much better than storing the password in the configuration file.
Another great solution would be to have something like srv.password_eval = pass transmission useful for people who use password managers like pass or gnome-keyring.

[rndusr]

Ok, thanks for reminding me. I think I'll stick with reading the env var. It's faster, easier to implement and avoids subprocesses. But feel free to try and convince me otherwise.

[doronbehar]

Haha, I liked that :)

Reading the environmental variable is a great start but as for having an option like password_eval just like in this programs:

• msmtp: https://wiki.archlinux.org/index.php/msmtp#GnuPG
• mutt: https://unix.stackexchange.com/a/20572
• vdirsyncer: http://vdirsyncer.pimutils.org/en/stable/keyring.html#command
• toxic (tox client): External Password Source JFreegman/toxic#434

[rndusr]

Thanks for the examples. I like the vdirsyncer approach where adding '.fetch' to a setting's name turns the value into a command. Maybe I can implement that somewhat elegantly. On the other hand, in your case, this wouldn't be as nice as adding a new setting because the password is part of the URL. You would have to get the password in a subshell, somehow insert it into the URL string, and `echo` that. Yuck. And I'm not even sure it would be useful for anything other settings.

[doronbehar]

What you said Yuck about is exactly what I'm doing in the .zsh_credentials file in my dotfiles repository.

[rndusr]

Not exactly, because you're inside an interpreter in your `.zsh_credentials`. The stig rc line would look something like this: `set srv.url:fetch 'sh -c "echo \"user:$(pass transmission)@host:port\""'` ... and I probably got the quotes/escapes wrong. It would be little neater if the command would be passed to /bin/sh, but still not as elegant as your env vars.

[doronbehar]

Oh now I understand, you were thinking of something similar to what they do in muttrc (as explained here: https://unix.stackexchange.com/a/20572).

Maybe you should enable splitting the srv.url into srv.host, srv.port, srv.user and optionally srv.password which could be interpreted with something similar to fetch. Then you won't have to worry to much about sub-shells and quotes, you could just make the fetch command by default interpreting a shell command. That's only one sub-shell if I'm correct.

[rndusr]

I originally decided against that to keep the list of settings small, but maybe that would be best. It would solve this issue elegantly and also issue #24 ('/' character in password). It would break backwards compatibility again, but luckily we're still in alpha stage so nobody can complain! :)

[doronbehar]

You are funny :),

I don't think It has to brake backwards compatibility, it might be possible to specify in the manual or something that srv.url is overriding srv.host, srv.port, srv.user and srv.password or the other way around but than you will still have to solve #24 elegantly. I guess it will be much easier for you to remove the srv.url and use only the above variables instead exactly as you said.

I'll agree with either of those choices :)

[rndusr]

Yeah, no, having two separate (sets of) settings for the same thing is definitely not going to happen. That's just asking for bugs and confused users. But thanks for your input. It's very much appreciated.

[doronbehar]

Thanks for you reaching out your users 👍, Hope to see it in the next version.
Cheers!

[rndusr]

I've extended the 'set' command so that you can now append ':eval' to the name
of a setting to indicate that the value is a command:

set connect.password:eval pass transmission

[doronbehar]

Works great! Thanks!

[pschmitt]

Sorry for necrobumping but I wanted to share that this makes it possible to use env vars in the config 👍

set tui.theme:eval echo $XDG_CONFIG_HOME/stig/themes/stig_darker_theme.txt

[ralyodio]

how do i set username?