It verifies whether it can actually connect to a system prior mainly because you have to do it anyways at one point and also to query system information to for example display the operating system name and logos. What exactly do you mean by on the fly here? Maybe I can improve the flow for use cases like yours, I personally have never dealt with keys in password managers.

Essentially yes. You are correct, it is not a service to host. Instead it is a desktop application that works on top of your existing CLI tools.

Thanks for the feedback!

• There is a custom shell functionality under add command -> shell command, however it’s not perfect so you have to see whether it works for your cases
• I am not sure whether direnv works when you create a custom shell environment in xpipe with an init script of cd , I can test that
• About connecting to docker containers and other hosts, you can in theory connect as any user. However some parts like an on demand sudo elevation is currently bugged, but will work soon.
• Yeah I can imagine that using it in a tiling window manager is not very pleasant, I honestly did not take these into account when designing it. However, I plan to get rid of separate dialog windows and merge them with the main window.

Oh I see, that went over my head 😀

What do you refer to here? The UI or something else? I haven’t heard the word gooey being used to describe an application before, but I’m also not a native speaker.

Yeah since the last time a lot of aspects were improved, including the GUI performance which was quite bad. I hope it works out now

There are certainly some similarities, i.e. you use both to connect and work on your remote systems. However, the main difference is that XPipe does not come with integrated connection capabilities or an integrated terminal. Everything is delegated to your tools, i.e. XPipe for example connects via your installed ssh command-client and launches the terminal emulator you choose, nothing is included in the application itself.

On a more fundamental level, XPipe is not aware of any protocols like SSH, SFTP, FTP, and more. Instead, XPipe creates a new process using for example your local ssh executable, which is usually the OpenSSH client. I.e. it launches the process ssh user@host in the background and communicates with the opened remote shell through the stdout, stderr, stdin of the process. From there, it detects what kind of server and environment, e.g. shell type, os, etc. you have logged into with that shell connection, and adjusts how it talks to the remote system from there

As a result of this approach, you can do stuff with XPipe that you can’t do with other tools like MobaXterm. One example would be connecting and accessing files on a docker container as there’s no real protocol to formally connect here by default. XPipe can simply execute docker exec -i sh to open a shell into the container and handle the file management through this opened shell by sending commands like ls, touch, and more.

More broadly, XPipe can work on any shell connection, regardless of how it is established. From its perspective, there’s no visible difference between a remote ssh connection, a shell in a docker container, or your local system shell.

Furthermore, MobaXterm is Windows only while XPipe is cross-platform.

Overall, XPipe makes it much less tedious to connect and access remote systems wherever they are located, especially if you have to go through multiple intermediate systems in between. Once you added a system to XPipe, you can just connect to it with your favorite terminal in one click just as you would do manually and also browse the file system. Having a graphical overview over all available remote connections and their file systems can make your life easier, especially if you work with many different remote systems, containers, clusters, and more.

If you just regularly connect to two simple servers via SSH, then you probably won’t get that much use out of this. But if you have many servers, gateway servers, containers, and other subsystems running, then it will make your life easier.

An update: The latest release now has full support for SSH tunnels and I reworked the downloading and transfer process in the file browser.

I managed to do that, so you can now try it out at: https://aur.archlinux.org/packages/xpipe. Let me know whether everything works for you there, I was only able to test it on one Manjaro VM.

I managed to do that, so you can now try it out at: https://aur.archlinux.org/packages/xpipe. Let me know whether everything works for you there, I was only able to test it on one Manjaro VM.

Yeah it could definitely show the currently running command, although it will be tricky to not spam the user with too many commands and information in short succession, but we will see.

I guess the main reason for the popularity of iTerm2 is that the normal Terminal.app is just a little bit too basic in terms of its features. It works fine but nowadays people expect a little bit more.

That is good to hear it works at least to some degree now. In theory, xpipe does detect your installed terminals at launch and will select the most appropriate (i.e. prefer iTerm2 over Terminal.app if iTerm2 is installed), however it seems like there are some false positives as is it quite difficult to properly check whether an app is installed somewhere on macOS.

The UI feedback is definitely on my TODO list, having a status bar for example that tells you exactly what is currently going on would be very nice to have instead of just a spinner or nothing at all. I will see what I can do there

That is unfortunate that you had to deal with these bugs. The challenge here is that every setup and shell environment people run this in differs and there was only so much testing I was able to do on my end. Reporting bugs is very helpful to me and they can usually get fixed pretty quickly.

If I can somehow launch a shell process into a container in podman, that should be easy to add

Alright, I will try to look into that and also try to make the interface and work flows more intuitive

I should be able to fix the download box not staying there when switching to the local environment. If you want to drag and drop files from one tab into another, you can drag the files, hover them over the tab you want to switch to, and then drop them there.

In theory you should be able to just drag the files out of the download box as normal files, so you should be able to drag them into the XPipe browser but also other applications running on your desktop. What are your system details so maybe I can try to reproduce that?

Yeah the initial woes should be ironed out fairly quickly. Each user runs this in a completely different environment, so it was to be expected that I didn’t account and prepare for some cases.

In the file manager, the main way of uploading files is to just drag and drop the files into the current directory, either from your local desktop environment or from another open tab in XPipe. For downloads, there should be a box on the bottom left where you can drag and drop remote files into. Once dropped into it, they are downloaded, and once it’s finished, you can then drag them into your local desktop environment just as you can do with local files. I guess this process can be made more intuitive though, I will try to figure things out.

An update: I was able to reproduce the issue of growing memory usage when frequently adding connections like containers. As long as you don’t add more connections continuously in a session, the memory shouldn’t really grow that much. So a restart should improve the situation.

That is unfortunate to hear about these performance issues. Performance was not my main focus initially as optimizations are always supposed to come later on, but I guess that time is now. How many connections do you have added in total? I was not able to reproduce anything getting over 1GB of main memory with like 50 total connections. Also, does restarting fix some of that?

The best way of diagnosing that issue would be a heap dump of the application, but that requires some effort of getting it and also sharing it somehow, but we could do that if you want.