"Local Hostname" macro (%h) prints remote hostname
jaybeers opened this issue · 7 comments
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).
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?
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:
- The remote system name (already exists as
%s) - The local system name (I think this is what
%his supposed to be) - Properties of the terminal (width, height, colors, font)
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.
I have corrected %h to be the hostname of where cssh is being run from. This is now in the master branch.
Can confirm that %h now works as expected. Thanks!
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.
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:
- CSSH_SERVERNAME - Host name of the remote system
- CSSH_HOSTNAME - Host name of the local system
- CSSH_USERNAME - Local user name of the user that invoked cssh
- CSSH_CONNECTION_STRING - (?) Seems to always contain the same thing as CSSH_SERVERNAME
- CSSH_CONNECTION_PORT - Blank in my testing, but I assume that's because I always use 22
- CSSH_VERSION - Version number of cssh
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.
It is a duplicate variable left in for backwards compatibility - I may look to remove it at some point