4 ms·

> Shell parsing is hard. No, shell parsing isn't hard. The SSH protocol is broken: "Now, the SSH wire protocol only takes a single string as the command" Th

> Shell parsing is hard. No, shell parsing isn't hard. The SSH protocol is broken: "Now, the SSH wire protocol only takes a single string as the command" This needs to be fixed. It should have an execve mode.

pabs3 5y ago
There is already a bug open for years: https://bugzilla.mindrot.org/show_bug.cgi?id=2283 https://bugzilla.mindrot.org/show_bug.cgi?id=2283
- jpxw 5y ago
  Including mails from the author of this article!
tyingq 5y ago
Good idea, but there's a history of user accounts with disabled or restricted shells for various reasons. And execve would bypass that. There's no real pattern/standard for disabled shells, so a fix would be tricky. I suppose you could at least support execve of the login shell plus the command line, but that's not what people are really looking for.
swiley 5y ago
I would rather say "because shell parsing is hard the ssh protocol is broken." If shell parsing weren't hard this wouldn't be an issue.
laurent123456 5y ago
Perhaps it's a case of using the wrong tool for the job? A shell is just a simple UI to easily run commands. When you start using it to run commands within Bash, within SSH, within remote Bash, then maybe it's time to use a different tool.
- deathanatos 5y ago
  That's what they're saying, though? They want to stop running commands through the shell, and start running them directly, with exec() family of functions. SSH's protocol currently makes that impossible. Sometimes, I need to run a command on a remote machine, and SSH is basically the protocol/tool for that. But I don't have a choice, but to involve the shell on the remote. (There might not be a shell locally: I've done SSH with libraries with Python. But you still have to escape for the remote's shell, and that is what makes this annoying.)

4 ms·

> Shell parsing is hard. No, shell parsing isn't hard. The SSH protocol is broken: "Now, the SSH wire protocol only takes a single string as the command" Th

by silvestrov 5y ago

pabs3 5y ago
There is already a bug open for years: https://bugzilla.mindrot.org/show_bug.cgi?id=2283 https://bugzilla.mindrot.org/show_bug.cgi?id=2283
- jpxw 5y ago
  Including mails from the author of this article!
tyingq 5y ago
Good idea, but there's a history of user accounts with disabled or restricted shells for various reasons. And execve would bypass that. There's no real pattern/standard for disabled shells, so a fix would be tricky. I suppose you could at least support execve of the login shell plus the command line, but that's not what people are really looking for.
swiley 5y ago
I would rather say "because shell parsing is hard the ssh protocol is broken." If shell parsing weren't hard this wouldn't be an issue.
laurent123456 5y ago
Perhaps it's a case of using the wrong tool for the job? A shell is just a simple UI to easily run commands. When you start using it to run commands within Bash, within SSH, within remote Bash, then maybe it's time to use a different tool.
- deathanatos 5y ago
  That's what they're saying, though? They want to stop running commands through the shell, and start running them directly, with exec() family of functions. SSH's protocol currently makes that impossible. Sometimes, I need to run a command on a remote machine, and SSH is basically the protocol/tool for that. But I don't have a choice, but to involve the shell on the remote. (There might not be a shell locally: I've done SSH with libraries with Python. But you still have to escape for the remote's shell, and that is what makes this annoying.)