Fish shell (and possibly others) don't support && command chaining about mutagen

[xenoscopic]

Thanks for the additional info @IngCr3at1on, it definitely narrows the issue down.

Regarding the error you saw after adding executability and running the command I gave you, that's good to see - I gave you the foo bar arguments in an attempt to produce exactly that error, so at least we know there's not some weirdness going on with the binary itself.

For your reference in debugging, the basic lifecycle of a Mutagen agent binary installation is that it tries to invoke (over SSH) ~/.mutagen/agents/<MUTAGEN_VERSION>/mutagen-agent, and if that doesn't exist, it extracts an agent binary from the agent binary bundle, scps it to ~/.mutagen-agent<RANDOM_UUID>, invokes chmod +x on the copied binary (this has to be done post-copy in order to support Windows systems, where there's no executability bit to set on the agent binary before copying), and then invokes ~/.mutagen-agent<RANDOM_UUID> install, which should move the temporary binary into the correct location.

It seems like what's happening is that the chmod +x step is failing. The chmod and install steps are done in one SSH command to save password entries for people who use password authentication without something like ControlMaster. This happens here. Any error in this step should propagate back up the error chain and be reported as an installation error. I'm not sure why it's not.

Are you using an obscure shell or a configuration that would prohibit commands of the form commandA && commandB? I assumed this was portable, but I've run into many Bash-isms over the years that I didn't realize weren't portable. It might be worth decomposing this construction into two separate commands and seeing if that fixes things.

A few other things that are worth asking about:

Does your home directory have a space in the path?

Is the path to your home directory exceptionally long?

Is your home directory not the default working directory for your SSH commands?

I'll see if anything else comes to mind, I'll get back to you. Maybe something in the installation strategy above sounds like it might not work for your setup?

Perhaps you can try to manually invoke installation? If you take the mutagen-agents.tar.gz bundle included with the release and extract the linux_amd64 binary, scp it to the remote machine (maybe to ~/.mutagen-agent00000), and then run ssh user@host "chmod +x ~/.mutagen-agent00000 && ~/.mutagen-agent00000 install" (note the necessary quotation marks), what is the output?

I appreciate your help with debugging. I definitely want to get this sorted out, because if it's not working on every system, it's not working.

[xenoscopic]

Thanks for the info! I'll probably just go ahead and decompose the operations then. The effect should be minor since ControlMaster is used on all POSIX systems and Windows users using password-based authentication will only need to enter their password one additional time. I'll aim to fix this for the next release, though that may be a few weeks away due to other work. If it looks like it'll be a while, I might put out a patch release.

[xenoscopic]

Thanks for the report. It's always good to have new configurations tested. This is probably something simple that Mutagen is doing wrong. Shouldn't be too hard to fix.

I assume both systems are amd64 (since you're using Arch)? I don't test agent binaries on every architecture, but even for the unofficial 386 and ARM Arch they should be fine.

On the machine that you're trying to connect to, do you see any files named ~/.mutagen-agent... where ... is a UUID?

Do you see anything in ~/.mutagen/agents? If you see any folders in there with names of versions, do they have mutagen-agent binaries inside? Are those executable? Can you execute them locally? Remotely? When trying to execute ~/.mutagen/agents/v0.2.0/mutagen-agent foo bar do you receive any output?

Non-standard port is fine. Is there anything in your shell initialization scripts that sets a weird console mode? Something weird in the SSH configuration (client or server) that disallows non-interactive logins?

That's all I can think of for now, but let me know how that goes.

[IngCr3at1on]

Hi @havoc-io thanks for the reply.

yes both machines are amd64

---

I looked and there were a whole bunch of mutagen agent files that had been created so I went ahead and deleted all of them and reset my sshd configuration back the way I wanted it to start fresh. I also confirmed that there were no present .mutagen files on my desktop as well.

---

after running create from the desktop and getting the reported error I checked on the laptop and I can see:

.mutagen-agent34b82055-7e0c-4e2a-97d8-8a217dcfec5f

This appears to be a non-executable binary. I went ahead and set it to executable just for a laugh and tried running it.

 ./.mutagen-agent34b82055-7e0c-4e2a-97d8-8a217dcfec5f foo bar
error: invalid number of positional arguments
usage: mutagen-agent should not be manually invoked

[IngCr3at1on]

@havoc-io the shell is it... Give this a test with fish running as the default shell on the client machine you should be able to reproduce my issue. In the meantime I actually had been needing to change the default shell back to bash on my laptop and instead drop into fish from the .bashrc (several reasons lol); because of that I just changed my default shell to bash and set my bashrc to drop me into fish. The session created fine after this and I'm just waiting on it to sync the files from alpha to beta.