4 ms·
To avoid confusion for future readers: the second part of the post, the part which contains the quote, talks about VS Code `ShellExedution` API. This API is unr
by matklad 5y ago
To avoid confusion for future readers: the second part of the post, the part which contains the quote, talks about VS Code `ShellExedution` API. This API is unrelated to node’s `child_process` module. The absence of clear docs on `ShellExecution` is one drawback of the API which is called out.
Separately from the factual response, I want to explicitly say that I don’t endorse such style of communication. Please do not blindly assume, and then pick on, on the lack of knowledge of other people (be it author of the post or abstract lot of developers).
Even when you actually find the lack of knowledge (rather than assuming it), do not scold people for it. It’s OK to not know things, we all learned them for the first time once.
- rvnx 5y agoYou are doing well I think. My comment was more about the situation where a newbie knows that he is handling dangerous operations but still copy-paste from StackOverflow without even thinking or reading. You went one-step ahead and wrote a summary so it wasn't about your situation. The only point where I fundamentally disagree is about ShellExecution. When you send a string to the shell for execution, it seems reasonable to expect >, semi-colons, pipes, and other shell operators to be interpreted by the shell unless you escape them.
- matklad 5y ago> When you send a string to the shell for execution, it seems reasonable to expect >, semi-colons, pipes, and other shell operators to be interpreted by the shell unless you escape them. Fully agree here. But the problem is the second overload, which can take an array of strings (so looks like a safe API), but concatenates them without escaping.
- rvnx 5y agoAh, ah. I wanted to say no, but after reading more and more the method they offer is actually much more evil than it seems. In the ShellExecution function, if you actually comes from C programming you can get confused: Could the parameter "string | ShellQuotedString" mean: "A string which has the binary flag ShellQuotedString on" = "A shell quoted/escaped string" +/- "a string of sub-type ShellQuotedString" which would imply that the developer has to take this responsibility. or it means "string || ShellQuotedString", as in param is a "string OR ShellQuotedString" which in this case the behaviour is unknown. (well, now I know it's the second one :| ) but it's fun to read