escape_sh() method generate nesting quotes string

[AinuX]

escape_sh method generated nesting quotes string, but in some cases, the nesting qutoes command is not worked in embed linux system.

For instance,

escape_sh("help") "'help'" then channel.exec_command("'help'") will not work, the actual worked command should be channel.exec_command("help"), "help" instead of "'help'".

modified the method as followed, it worked in my case and tried with several scenarios with various linux system, it always worked fine.

def escape_sh(value):

• return "'" + value.replace("'", "'\''") + "'"
• return value.replace("'", "'\''")

[mwilliamson]

I think the edit you've made will mean that strings aren't properly escaped in some cases. On your embedded Linux system, does the shell not support single quote strings at all?

[AinuX]

yes, the shell doesn't support single quote string, otherwise an “unrecognize command” error will rise.

[mwilliamson]

Do you know what the shell actually is? Since I don't know of a reliable way to determine what the shell is, manually specifying the shell type might be the best solution.

[AinuX]

Actually, it's the IBM's Intergrated Management Module II (IMM2 ) console, and I cannot change the shell type because the limited permisson in the terminal.

[mwilliamson]

Thanks for the information. To clarify: I was suggesting that you can could configure spur with the shell type, since it needs to know the shell type to know how to handle escaping. Do you know what escaping IMM2 supports?

[AinuX]

################################### system> 'help' Error: Command not recognized. Type 'help' to get list of supported commands. system> "help" ? -- Display command list xxxx xxxx ...... system>help ? -- Display command list xxxx xxxx ...... ###################################

According to the test, the command with double qutoe or without qutoe will be sucess.

[mwilliamson]

Thanks. Do you know if quoting using double quotes behaves as it does in sh i.e. still allows things like variable expansions? Spur uses single quotes to ensure this doesn't happen.

[AinuX]

Found a post about the topic about "What’s the Difference Between Single and Double Quotes in the Bash Shell?", so seems that the double quotes have better capability than the single one.

[AinuX]

the link about the post: http://www.howtogeek.com/howto/29980/whats-the-difference-between-single-and-double-quotes-in-the-bash-shell/

[mwilliamson]

Unfortunately, that post is specific to bash: I'm asking about the shell that IMM2 uses, which isn't bash (since it doesn't support single quotes). Specifically, how do double quotes behave in your shell?

[AinuX]

Command with double quotes in IMM2 worked well as it in bash does.

[mwilliamson]

Sorry, I don't quite understand your last statement. Are you saying the double quotes in IMM2 work the same as in bash? If that's the case, then double quotes aren't appropriate, since they will still allows things like variable expansion.

[AinuX]

In IMM2 console,

system> "ifconfig eth0" not work Error: Command not recognized. Type 'help' to get list of supported commands. system> ifconfig eth0 ..... worked system> ifconfig "eth0" ...... worked system> "ifconfig" eth0 ......worked

[AinuX]

def escape_sh(value): return '"'+value.replace("'", "'\''")+'"' ====> worked

def escape_sh(value): return value.replace("'", "'\''") ====> worked

def escape_sh(value): return "'" + value.replace("'", "'\''") + "'" ====> not work

[mwilliamson]

Could you try running some commands where double quotes and single quotes would produce different results in bash? For instance, what does echo "$PATH" do? For spur to work properly, this needs to print out the literal value $PATH, rather than the value of the environment variable. More generally, it needs to make sure that no shell features are being used.

[mwilliamson]

Closing since it's not clear to me what the correct behaviour would be (since I don't have access to the shell in question). If anybody else has a similar problem and knows how the escaping works for their terminal, then I'd be happy to add another shell type.