Formatters::Pretty: display command being run

[steved]

It seemed odd to see the /usr/bin/env prefix when that wasn't the command being run.

[robd]

I just wanted to make sure I understand exactly what the problem here is. Eye balling the code, it looks like this bug is that commands which don't use the command mapper (ie ones with spaces in), are incorrectly logged as if the command mapper had been applied. For commands which do use the command mapper, then the log line is correct. Have I understood this right?

One thing I wanted to check, for a command with a lot of options applied, would this change make the log line very long (ie commands which are wrapped with umask, within, user etc would now print out all of the wrapping details). From the looks of the code, the intention is not to print all this stuff out for commands using the command mapper. I haven't tried this so I'm not sure if I misunderstood something.

[steved]

Ah, I see what you're saying. Would this be ok? I know it isn't DRY, but the methods are so close anyway:

diff --git a/lib/sshkit/command.rb b/lib/sshkit/command.rb
index d3787d3..cdf9811 100644
--- a/lib/sshkit/command.rb
+++ b/lib/sshkit/command.rb
@@ -206,7 +206,11 @@ module SSHKit
     end

     def to_s
-      [SSHKit.config.command_map[command.to_sym], *Array(args)].join(' ')
+      if should_map?
+        [SSHKit.config.command_map[command.to_sym], *Array(args)].join(' ')
+      else
+        command
+      end
     end

[mattbrictson]

I think this needs to be command.to_s, because command may be a symbol.

[steved]

Yep, done

[steved]

bump

[mattbrictson]

This looks good, but I haven't had time to think through the consequences. My guess is that Command#to_s is used a lot, either explicitly or within string interpolation. Have you tried doing a cap deploy against this branch?

[steved]

Yep, looks alright to me. Unfortunately, I'm new to v3 so I'm not 100% sure what the implications are either.

[mattbrictson]

OK, I've now tested it as well. Seems good to me! 👍

[steved]

@leehambley

[steved]

Thanks! Do you mind releasing a new version?

[leehambley]

Next week proobably
On 18 Dec 2015 7:30 p.m., "Steven Davidovitz" [email protected]
wrote:

Thanks! Do you mind releasing a new version?

—
Reply to this email directly or view it on GitHub
#304 (comment).