<story><title>Rich Command Shells</title><url>http://waywardmonkeys.org/2014/10/10/rich-command-shells/</url></story><parent_chain><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><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></comment>
<story><title>Rich Command Shells</title><url>http://waywardmonkeys.org/2014/10/10/rich-command-shells/</url></story><parent_chain><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><author>aduitsis</author><text>Exactly as you indicate, even in &amp;quot;classic&amp;quot; terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their usefulness?&lt;p&gt;So why shouldn&amp;#x27;t we have a couple of extra escape sequences where the terminal could, e.g. draw an arbitrary bitmap? You are right, that would certainly require some sort of standard becoming prevalent, but why would a little extra capability (that doesn&amp;#x27;t break compatibility) be a bad thing?</text></comment>