cmd icon indicating copy to clipboard operation
cmd copied to clipboard

handling quoted arguments

Open progrium opened this issue 8 years ago • 2 comments

Consider a shell command:

$ foobar arg1 "this is arg2" arg3

When it comes to the syscall that executes a program, arguments are represented as structured data: an array. In this case, we'd expect an array of 3 elements, the second having spaces. (Technically, 4 elements, the first being the program name)

When the program gets these arguments, the quotes are not there. The quotes are an artifact of the shell as a solution to interpreting arguments with spaces, since obviously spaces are used to separate arguments. Quoting is a POSIX standard, but different shells can achieve quoting in lots of different ways. For example, imagine a shell that is more like a modern programming REPL and arguments are separated by commas.

For whatever reason, the SSH protocol was not implemented with an awareness of structured arguments. The command above would be encoded as a string foobar arg1 this is arg2 arg3.

We perform POSIX lexing on the receiving end, but by then we've lost the quotes. In order to get around this, we can double quote:

$ ssh server.com foobar arg1 '"this is arg2"' arg3

Which is encoded as foobar arg1 "this is arg2" arg3. You might think, wait how do we do this normally with SSH? What's typical is to quote the whole command string, and quoting within it, because it's understood that we're encoding a string representing the command to execute on the other end and the other end will parse it depending on the shell it's run through.

$ ssh server.com "foobar arg1 'this is arg2' arg3"

This conceptual model makes sense traditionally. However, the expectations cmd.io sets up are different. We treat it almost like a local CLI client. We expect this to work:

$ ssh cmd.io foobar arg1 "this is arg2" arg3

But it doesn't. We could suggest either of the above double quoting workarounds, however, I think this will be common enough that it would intrude on the expectation/illusion we're trying to maintain.

My proposed solution is to provide an alternative to argument quoting:

$ ssh cmd.io foobar arg1 [this is arg2] arg3

This will be encoded as foobar arg1 [this is arg2] arg3, which we can then parse into proper arguments. POSIX shells don't treat [] as special characters and probably never will because of the [ and [[ "commands". In the rare case this is not possible for a user (using some weird shell that uses []), we can then suggest double quoting.

Thoughts?

progrium avatar Feb 06 '17 22:02 progrium

Either way, we'll have to educate users. So it's a matter of whether we want to educate them using double quotes or with square brackets. I have no problem explaining a summary of the quoting problem and providing both as workarounds. My feeling is the square brackets are going to seem more natural to most users given an understanding the problem. In other words, they'd rather do this than get double quoting right. In fact, veteran shell users might even prefer this.

progrium avatar Feb 06 '17 22:02 progrium

Quoting the entire ssh command works well and is fairly standard practice when all you want to do is run one command on a host over ssh. Users should probably be used to that already and providing single quotes for multi word args is trivial.

joebwan avatar May 10 '17 20:05 joebwan