Added tramp-devel@gnu.org in the CC for archiving purposes, as suggested before by you.
While trying to find a temporary hack to satisfy my own need, I realized what you said: "This semantic isn't used only in tramp-sh-handle-get-home-directory, but everywhere in Tramp. " So it is not something as simple as changing this one function. But regarding the concept of "user" and "home directory", I have some different opinions. 1. I support the idea of expanding the tramp syntax so it can cover wider cases, such as k8 namespace (or even context?) mentioned in your email. As much as I like kubel, it is a bit of a pain that only one name space can be used at one time. 2. However, that should not prevent us from handling the existing syntax better 3. "The point is, that in kubel the Tramp user is misused to be the (optional) container name.". We certainly can say that. But on the other hand, I think we also can ask: do we need to restrict the "user" part of the tramp syntax to an actual user name whose "echo ~<user_name>" must produce a valid home directory? What is the benefit of having that restriction? Do we gain anything by NOT returning the correct home directory simply for the sake of maintaining a "pure" definition of the "user" part of the tramp file syntax? 4. Even if for certain reasons (existing code, for example), changing the definition of "user" part in a tramp file name is not desired or practical (so we maintain the objection to the syntax "kubel" uses), we may still separate how the home directory is retrieved from the user itself. That's what Emacs 26.3 did (hence I noticed this "regression" while upgrading Emacs). It retrieves the home directory by sending "cd; pwd" to the shell process of the tramp connection. I am speaking from the perspective of a regular user who does not really know the internals and history of tramp well, so I may well have missed some important design principles that invalidate my above points. But maybe an outsider sometimes can also give some fresh viewpoints? :-) Best regards. Warren On Tue, Jun 20, 2023 at 6:15 AM Michael Albinus <michael.albi...@gmx.de> wrote: > Warren Lynn <wrn.l...@gmail.com> writes: > > Hi Warren, > > > I will check out the built in kubernetes but it seems to me the > > "kubel" package has its own unique features also. More to the point is > > that this is a generic issue (user in the method may not be a true > > Linux account user), and we may make tramp more robust with those > > cases. > > The user in a Tramp file name shall be a user. This semantic isn't used > only in tramp-sh-handle-get-home-directory, but everywhere in Tramp. > > It doesn't need to be a Linux user, it could be a user in any remote > OS. See all the different Tramp methods *not* specified in tramp-sh.el. > > The point is, that in kubel the Tramp user is misused to be the > (optional) container name. I don't believe that we shall support such > hacks. Instead, we shall extend the Tramp syntax to be able to determine > the container name explicitly. > > As said in my other message, there is bug#59797 which proposes an > extension for name spaces. Instead of saying > "/kubernetes:POD:/path/to/file", > we could also allow "/kubernetes:POD.NAMESPACE:/path/to/file". Extending > this, we could even go to > "/kubernetes:CONTAINER.POD.NAMESPACE:/path/to/file" > syntax, with "CONTAINER." and ".NAMESPACE" being optional. This is for > Tramp's own tramp-container.el implementation, but this could also be > married with kubel.el. > > > Thanks again for working on the tramp package. I rely on it heavily. > > WDYT? > > > Warren > > Best regards, Michael. >
