search

duncs / clusterssh

Cluster SSH - Cluster Admin Via SSH
https://github.com/duncs/clusterssh/wiki
890 stars 79 forks source link

"Local Hostname" macro (%h) prints remote hostname #116

Closed jaybeers closed 4 years ago

jaybeers commented 5 years ago

When you choose Local Hostname from the Send menu, what actually types out in the session is the remote hostname. More specifically, the %h macro expands to the remote hostname (instead of the local hostname, as it should); I tested it by creating a custom send_menu file, to make sure it actually was the macro expansion and not something with the UI.

Speaking of which: in related news, is there any documentation (beyond what's in the manpage) on creating a send_menu file? I was ready to go crazy with dynamic auto-typing, but from what I can suss out it seems like you're limited to verbatim text strings, except for the five macros. I see in the default menu where you can insert a random number, but that appears to be hardcoded into the application (and not reproducible with a custom menu definition).

duncs commented 5 years ago

Perhaps you want the %s macro for servername (-l by default) rather than %h?

Can you provide more details about what you would like to put in the menu? Output from running another command or what?

jaybeers commented 5 years ago

As far as the existing macros: I wouldn't say I want either of them; I just noticed that %s and %h were printing the same thing when I was playing with the stuff in the Send menu. :) I'm not saying that to nitpick, I'm just pointing out that I don't personally have a horse in this race so any information I provide will inherently be in the abstract.

As far as what I'd like for the menu: TLDR version...arbitrary command output, yes please!

The (much) longer version):

Being able to run an arbitrary command means I can create whatever I like without having to put the burden on upstream ClusterSSH for implementation. At that point, ClusterSSH could simply focus on providing more "data macros" to be used as command line options for the user-developed scripts:

If executing arbitrary commands does become possible, it'd be really nice to be able to populate environment variables in their (the scripts') environments. For example, the ROWS, COLUMNS, USER, and REMOTEHOST variables could be pre-configured in the script's environment to match what they would be if the command were running in that terminal.

I know a lot of this sounds like overkill, and that's because it is. :) The extra macros, environment variables, etc. are just a vision to account for edge cases to do wacky stuff. At the end of the day, just being able to execute arbitrary commands with the existing %h macro on the command line would allow me to make everything that's occurred to me so far.

duncs commented 5 years ago

I have corrected %h to be the hostname of where cssh is being run from. This is now in the master branch.

jaybeers commented 5 years ago

Can confirm that %h now works as expected. Thanks!

duncs commented 5 years ago

I have added in some user defined macros along with some examples of how they might be used in the docs. Please check it out.

jaybeers commented 5 years ago

Looks good. :) I tested the following config:

macro_user_1_command=echo -n "a string without a ${CSSH_SERVERNAME} newline at the end"
macro_user_2_command=echo 'a string with a ${CSSH_SERVERNAME} newline at the end'
macro_user_3_command=env | grep CSSH
macro_user_4_command=echo ${CSSH_SERVERNAME}

...and it worked as expected; I thought I was going to be clever with my use of different quotes but it all did the right thing (i.e the first and fourth macros printed the server name, and the second macro printed the literal string ${CSSH_SERVERNAME}.

These seem to be the contents of the environment variables, based on my testing:

What is CSSH_CONNECTION_STRING meant to contain? It was always the plain hostname of the target/remote system, regardless of whether the original cssh command line contained plain hostnames, hostnames resolved using external_cluster_command, or cluster names defined in ~/.clusterssh/clusters.

duncs commented 4 years ago

It is a duplicate variable left in for backwards compatibility - I may look to remove it at some point