<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>mwcampbell</author><text>&amp;gt; Putting commands and data inline is a recipe for disaster and a million command injection exploits. The Unix philosophy has broken the minds of generations of programmers. It leads them to doing things like concatenating strings to build SQL queries or doing IPC with ad-hoc regex-parsed protocols or using a couple of magical characters to indicate that the contents of a variable should be parsed and executed instead of just stored.&lt;p&gt;Yes! And then to compensate, they have to &amp;quot;sanitize&amp;quot; untrusted input to their systems. I had a meeting yesterday with a developer and a project manager at an organization that wants to work with my company to integrate one of our products with one of theirs. I mentioned the possibility of submitting some data in JSON format to a web API on their end, and the project manager asked about the risk of code injection attacks, by which he apparently meant SQL injection. I had to assure him, based on my knowledge of their tech stack (Node.js, CouchDB, and naturally, JSON) that code injection wouldn&amp;#x27;t be an issue. My point is that the common abuses of strings by Unix and web developers have led to well-known and widely feared security vulnerabilities which just don&amp;#x27;t exist in software that&amp;#x27;s built on a foundation of properly structured data.&lt;p&gt;See also this classic by Glyph Lefkowitz:&lt;p&gt;&lt;a href=&quot;https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;glyph.twistedmatrix.com&amp;#x2F;2008&amp;#x2F;06&amp;#x2F;data-in-garbage-out....&lt;/a&gt;</text><parent_chain><item><author>anon1385</author><text>Text isn&amp;#x27;t the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. &amp;#x27;Text&amp;#x27; is a very seductive abstraction, but it&amp;#x27;s one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on.&lt;p&gt;Putting commands and data inline is a recipe for disaster and a million command injection exploits. The Unix philosophy has broken the minds of generations of programmers. It leads them to doing things like concatenating strings to build SQL queries or doing IPC with ad-hoc regex-parsed protocols or using a couple of magical characters to indicate that the contents of a variable should be parsed and executed instead of just stored. Take a read of some of the earlier threads on HN about &lt;i&gt;Shellshock&lt;/i&gt;, and you will find numerous people blaming Apache for not &amp;quot;escaping&amp;quot; the data it was putting in a shell variable. As if it even could.&lt;p&gt;Even Unix nerds have at least partially internalised the dangerousness of the paradigm -- &amp;quot;don&amp;#x27;t parse the output of ls&amp;quot; and so on. The fact that the Unix paradigm (passing everything as strings with magical characters and escape sequences) is broken for the most fundamental computing tasks like working with file names ought to be a damning inditement of the paradigm. Sadly people merely parrot the rote learned lesson &amp;quot;don&amp;#x27;t parse ls because file names can&amp;#x27;t be trusted&amp;quot;, without thinking about all the other untrusted data they expose to unix shells all the time.&lt;p&gt;Just this week Yahoo got exploited. At first people thought it was &lt;i&gt;Shellshock&lt;/i&gt;, but no, it was just a routine command injection vulnerability in their log processing shell scripts. A problem blighting just about every non-trivial shell script ever written.&lt;p&gt;The usual reply is &amp;quot;don&amp;#x27;t use shells with untrusted data&amp;quot;. But auditing where any particular bit of data came from can be just about impossible once it has been across several systems through programmes written in a variety of languages, stored on a file system, read back and so on. The only sane solution is to never use shell scripts.&lt;p&gt;Like the C memory and integer model makes writing secure C code borderline impossible, the Unix &amp;quot;single pipe of bytes that defaults to being commands&amp;quot; paradigm makes writing secure shell scripts borderline impossible.&lt;p&gt;Unix needs to be taken out back and shot.</text></item><item><author>zorbo</author><text>Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It&amp;#x27;s compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it.&lt;p&gt;The command line works with text. The command line remains the best interface I&amp;#x27;ve ever used. It&amp;#x27;s user friendly, composable and available everywhere. It&amp;#x27;s easy to automate and easy to extend.&lt;p&gt;I wish the &amp;quot;command line with pictures&amp;quot; idea would just go away already. It adds nothing for the general public. I can already view pictures on remote machines with X forwarding.&lt;p&gt;Command line with pictures never made it, because there are ten competing standards. With text, everybody just agreed on ASCII and now Unicode&amp;#x2F;UTF8. Text has hundreds of ugly clutches on top of it (Extended ASCII, ANSI, Escape codes, etc, etc). It still works. It&amp;#x27;s still simple. It has its problems, but nowhere near as many problems as GUIs.&lt;p&gt;Those who don&amp;#x27;t understand Unix are doomed to reimplement it... poorly.</text></item></parent_chain></comment><story><title>Rich Command Shells</title><url>http://waywardmonkeys.org/2014/10/10/rich-command-shells/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jschwartzi</author><text>I would not be half as capable of troubleshooting in my work as I am if I couldn&amp;#x27;t parse random byte strings on the command line. That alone is why I use Unix for embedded development. Powerful things are often dangerous. For instance, consider nuclear power, motor vehicles, rocket engines, medicine, plastics, et. al..&lt;p&gt;So how do you provide the same level of capability as C and UNIX but without mixing data and commands? Is there some alternative paradigm that is just as powerful but safe?</text><parent_chain><item><author>anon1385</author><text>Text isn&amp;#x27;t the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. &amp;#x27;Text&amp;#x27; is a very seductive abstraction, but it&amp;#x27;s one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on.&lt;p&gt;Putting commands and data inline is a recipe for disaster and a million command injection exploits. The Unix philosophy has broken the minds of generations of programmers. It leads them to doing things like concatenating strings to build SQL queries or doing IPC with ad-hoc regex-parsed protocols or using a couple of magical characters to indicate that the contents of a variable should be parsed and executed instead of just stored. Take a read of some of the earlier threads on HN about &lt;i&gt;Shellshock&lt;/i&gt;, and you will find numerous people blaming Apache for not &amp;quot;escaping&amp;quot; the data it was putting in a shell variable. As if it even could.&lt;p&gt;Even Unix nerds have at least partially internalised the dangerousness of the paradigm -- &amp;quot;don&amp;#x27;t parse the output of ls&amp;quot; and so on. The fact that the Unix paradigm (passing everything as strings with magical characters and escape sequences) is broken for the most fundamental computing tasks like working with file names ought to be a damning inditement of the paradigm. Sadly people merely parrot the rote learned lesson &amp;quot;don&amp;#x27;t parse ls because file names can&amp;#x27;t be trusted&amp;quot;, without thinking about all the other untrusted data they expose to unix shells all the time.&lt;p&gt;Just this week Yahoo got exploited. At first people thought it was &lt;i&gt;Shellshock&lt;/i&gt;, but no, it was just a routine command injection vulnerability in their log processing shell scripts. A problem blighting just about every non-trivial shell script ever written.&lt;p&gt;The usual reply is &amp;quot;don&amp;#x27;t use shells with untrusted data&amp;quot;. But auditing where any particular bit of data came from can be just about impossible once it has been across several systems through programmes written in a variety of languages, stored on a file system, read back and so on. The only sane solution is to never use shell scripts.&lt;p&gt;Like the C memory and integer model makes writing secure C code borderline impossible, the Unix &amp;quot;single pipe of bytes that defaults to being commands&amp;quot; paradigm makes writing secure shell scripts borderline impossible.&lt;p&gt;Unix needs to be taken out back and shot.</text></item><item><author>zorbo</author><text>Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It&amp;#x27;s compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it.&lt;p&gt;The command line works with text. The command line remains the best interface I&amp;#x27;ve ever used. It&amp;#x27;s user friendly, composable and available everywhere. It&amp;#x27;s easy to automate and easy to extend.&lt;p&gt;I wish the &amp;quot;command line with pictures&amp;quot; idea would just go away already. It adds nothing for the general public. I can already view pictures on remote machines with X forwarding.&lt;p&gt;Command line with pictures never made it, because there are ten competing standards. With text, everybody just agreed on ASCII and now Unicode&amp;#x2F;UTF8. Text has hundreds of ugly clutches on top of it (Extended ASCII, ANSI, Escape codes, etc, etc). It still works. It&amp;#x27;s still simple. It has its problems, but nowhere near as many problems as GUIs.&lt;p&gt;Those who don&amp;#x27;t understand Unix are doomed to reimplement it... poorly.</text></item></parent_chain></comment><story><title>Rich Command Shells</title><url>http://waywardmonkeys.org/2014/10/10/rich-command-shells/</url></story>