4 ms·

This is probably an instance of the DWIM principle. You want this tool to do a thing when you invoke it a certain way, but its objectives and methods differ fro

This is probably an instance of the DWIM principle. You want this tool to do a thing when you invoke it a certain way, but its objectives and methods differ from yours, so despite best intentions on both sides, you end up with unexpected behavior. Argument parsing, whitespace detection, tokenizing a string, these are really difficult things even when a remote host is not involved. Try writing a shell script that always handles variables so perfectly that you can access any pathname in the filesystem, whether it has spaces, tabs, unprintables, Unicode, or whatever. There are, of course, solutions, or at least workarounds to this. ssh can be configured on the receiving side so that it runs a particular command, and parsing whitespace/arguments should be significantly easier when you configure it this way. Alternatively, you could write custom Bash or Python to do what you want, and just have that tool on the receiving end. (The latter assumption is easier said than done!) Configuring ssh to run a dedicated command line is probably an underutilized, underrated mode of operation. I used it to safely operate LAN backups: I had a client machine that would ssh in to a special user account, which had no actual shell, but immediately kicked off the backup process. That's the stereotypical use. But for ad hoc use cases, like this blogger was probably trying to implement, you don't really have a chance to pre-populate the receivers with scripts or special configurations. And yeah, that becomes a pain when you're trying to do a clever one-liner and it chokes. I feel your pain. (Have you considered improvising a Python or Perl one-liner for ssh to run?)

harry8 3y ago
>[can't] pre-populate the receivers with scripts or special configurations Write a script in say, python. Then from memory you can do something like: $ ssh $remotehost python < script Wrap that in a for remotehost in ${hosts[@]}; do Maybe? Has some merit on occasion.
marcosdumay 3y ago
> DWIM principle This is an instance of the problems caused by throwing everything into a simple plain stream, instead of having a modal stream that can tell what kind of thing is going there. Try writing a python script that always handles variables so perfectly that you can access any pathname in the system. It's funny to even write that, because it's trivial (barring UTF-8 issues that require using a non-obvious API). But you can only do that because of those annoying quotes that create a new idiom inside them. Sh saves you from that annoyance.
Wicher 3y ago
> ssh can be configured on the receiving side so that it runs a particular command Yes — but it will always, ALWAYS launch your shell as (typically) defined in /etc/passwd, and will pass it two string arguments: "-c" "and your particular command with arguments and all". Go strace it, go look at the argument vector, you'll see. Thus if your shell is bash, zsh, tcsh, dash, sh, whatever: the moment that it sees and tokenizes "and your particular command with arguments and all", you'll have lost. The only winning move is not to play. > Configuring ssh to run a dedicated command line is probably an underutilized, underrated mode of operation. Perhaps, but in any case, it doesn't save you. As I explained above, your shell runs first, so you've already lost. Maybe it's not underrated, maybe it's rated exactly right because of this problem! But what if I tell you you can make your problems go away. You juuuuuust have to use this very special shell. I don't want to be downvoted for linking it for a third time on this page, so I won't. Thus: see my other comments on this page :-)

harry8 3y ago

>[can't] pre-populate the receivers with scripts or special configurations Write a script in say, python. Then from memory you can do something like: $ ssh $remotehost python < script Wrap that in a for remotehost in ${hosts[@]}; do Maybe? Has some merit on occasion.

marcosdumay 3y ago

> DWIM principle This is an instance of the problems caused by throwing everything into a simple plain stream, instead of having a modal stream that can tell what kind of thing is going there. Try writing a python script that always handles variables so perfectly that you can access any pathname in the system. It's funny to even write that, because it's trivial (barring UTF-8 issues that require using a non-obvious API). But you can only do that because of those annoying quotes that create a new idiom inside them. Sh saves you from that annoyance.

Wicher 3y ago

> ssh can be configured on the receiving side so that it runs a particular command Yes — but it will always, ALWAYS launch your shell as (typically) defined in /etc/passwd, and will pass it two string arguments: "-c" "and your particular command with arguments and all". Go strace it, go look at the argument vector, you'll see. Thus if your shell is bash, zsh, tcsh, dash, sh, whatever: the moment that it sees and tokenizes "and your particular command with arguments and all", you'll have lost. The only winning move is not to play. > Configuring ssh to run a dedicated command line is probably an underutilized, underrated mode of operation. Perhaps, but in any case, it doesn't save you. As I explained above, your shell runs first, so you've already lost. Maybe it's not underrated, maybe it's rated exactly right because of this problem! But what if I tell you you can make your problems go away. You juuuuuust have to use this very special shell. I don't want to be downvoted for linking it for a third time on this page, so I won't. Thus: see my other comments on this page :-)