#17 generalize PassCmd & co. to IncludeCmd

[Demis Balbach]

Hello,

I recently faced a situation where I set up a work email account which had out of the ordinary credentials (User wasn't the same as email and Host was very specific as well. my mbsync config is part of my dotfiles, but I don't want to share information like this publicly. We have PassCmd for hiding passwords, would it be possible to implement something similar for Host and User, like HostCmd and UserCmd?

It could function exactly the same, as in it would just expect a command to be executed.

Thanks in advance.

[Oswald Buddenhagen]

UserCmd is in fact in 1.4.

but it kinda gets weird with HostCmd. we'd have to add PortCmd as well, and for good measure TunnelCmd, and while we're at it AccountSectionCmd.

at this point, it seems more pragmatic to me to autogenerate the config file, possibly using a .mbsyncrc.in with some @placeholder@s. with bash, it should be possible to use mbsync -c <(sed -e 's/@placeholder1@/.../;...' < ~/.mbsyncrc.in).

[Demis Balbach]

Hello.

UserCmd is in fact in 1.4.

Ah nice. Good to know, thanks!

at this point, it seems more pragmatic to me to autogenerate the config file, possibly using a .mbsyncrc.in with some @placeholder@s

I can't really judge what's better from a developer point of view. But as a user, I'd appreciate something simple like a HostCmd. To me, this actually seems more pratical than your suggestion, because I cloud save the data alongside my other mail related data (in my password store) and retrieve them in similar fashion to user and password. It's already working like that for those anyway.

I can't tell you where to draw the line in terms of Port, Tunnel and so on. I understand it can be a difficult decision.

[Oswald Buddenhagen]

I cloud save the data alongside my other mail related data (in my password store) and retrieve them in similar fashion to user and password.

i suppose, but this feels just wrong to me. even UserCmd was a bit of a stretch, but at least it still fits within "login credential". going beyond that, you enter the realm of generalized scriptability. i could facilitate that by introducing Include and IncludeCmd commands and/or (environment) variable expansions, but this all seems like an awful lot of trouble for something that has been requested exactly once so far.

[Demis Balbach]

Hello,
it's been a couple of months, sorry for that.

Instead of implementing userCmd, hostCmd and whatnotCmd, how about a general eval command that executes the given command and returns the first line of its output to the config file. So a simple example would be

eval echo "User \"me@example.org\""

would yield

User "me@example.org"

That way, you could get rid of all the other commands and have that be a generic solution and have the users then deal with it themselves. This is actually how msmtp implemented a similar feature: https://github.com/marlam/msmtp-mirror/issues/73

Cheers!

[Oswald Buddenhagen]

this is exactly the same thing as the IncludeCmd i proposed above.
a theoretical advantage of that vs. just generating the complete config file is that you don't need a wrapper executable, as isync acts as the "driver".
on the downside, you're constrained in what you can actually do, and making other options' values available to the executed command requires some kind of "expando" feature, which is even more additional complexity.

[Demis Balbach]

this is exactly the same thing as the IncludeCmd i proposed above.

You are correct. Sorry I didn't go through our conversation again once I came back.

on the downside, you're constrained in what you can actually do, and making other options' values available to the executed command requires some kind of "expando" feature, which is even more additional complexity.

Could you name an example for that? To me it sounds like a reasonable idea. If you envision it acting like I described in my recent post than that's everything I would need. Plus it may make UserCmd obsolete.

I get that this may be much asked from 1 person. But I can imagine many people taking advantage of it since it would facilitate an abstract command anyone could use of anything they want.

[Oswald Buddenhagen]

to avoid redundancy in the config file, one would want to use other options' values in the command. this can be done more uniformly when the whole config file is generated from a template.

but then, this problem of course already exists with PassCmd, so it's actually orthogonal (though it would be aggravated if one used a separate Eval command for every substituted option).

[Demis Balbach]

Ok, so what do you propose?

[Oswald Buddenhagen]

we can go with a plain IncludeCmd - popen() the command as-is and parse the output as if it appeared inline. it's not worse than the existing *Cmds, so fair enough.

it may take a while until i get to it. patches welcome!

[Kowalski]

something that has been requested exactly once so far

I was looking for this too, and i'm sure many others were as well

[Oswald Buddenhagen]

you may want to give the wip/includecmd branch a shot.