<story><title>Introducing nushell</title><url>http://www.jonathanturner.org/2019/08/introducing-nushell.html</url></story><parent_chain><item><author>entangledqubit</author><text>I&amp;#x27;ve been delving into bash scripting a bit more than I&amp;#x27;d like as of late and the lack of universally available consistent structured output for the CLI really got to me.  Most of the script contents end up being these obfuscating and brittle &amp;quot;hacky solutions&amp;quot; that never should have been necessary.  When I thought about pursuing fixing this I felt like the task was a bit overwhelming.  I&amp;#x27;m delighted that these developers are working on this!</text></item><item><author>pixelmonkey</author><text>The compelling idea here is that they convert the output of common shell commands into tabular data that can be manipulated using common operators, so that you don&amp;#x27;t have the remember sorting&amp;#x2F;filtering&amp;#x2F;grouping flags that may be different for every different shell command. So, imagine being able to use the same sorting&amp;#x2F;filtering logic on the output of `ls` as you might on the output of `ps`, and without relying on hacky solutions like pipelines to `grep`, `cut`, and `sort`.&lt;p&gt;It also means shell command output can be easily transposed into JSON and CSV. Actually pretty clever!</text></item></parent_chain><comment><author>bigtrakzapzap</author><text>The key flaw of UNIX philosophy is destructuring deserialization and reserialization based on lines, necessitating all manner of argument escaping and field delimiters, when pipelines should be streams of typed messages that encapsulate data in typed fields. Logs especially (logging to files is a terrible idea, because it creates log rotation headaches and each program requires a log parser because of the loss of structured information) also. Line-oriented pipeline processing is fundamentally &lt;i&gt;too simple.&lt;/i&gt; Settling on a common data simple&amp;#x2F;universal format robust enough for all purposes, including very large data sets, to exchange between programs and is just complicated enough to eliminate escapement and delimiter headaches without throwing away flexibility (by a new&amp;#x2F;refined set of processing tools&amp;#x2F;commands) is key.</text></comment>
<story><title>Introducing nushell</title><url>http://www.jonathanturner.org/2019/08/introducing-nushell.html</url></story><parent_chain><item><author>entangledqubit</author><text>I&amp;#x27;ve been delving into bash scripting a bit more than I&amp;#x27;d like as of late and the lack of universally available consistent structured output for the CLI really got to me.  Most of the script contents end up being these obfuscating and brittle &amp;quot;hacky solutions&amp;quot; that never should have been necessary.  When I thought about pursuing fixing this I felt like the task was a bit overwhelming.  I&amp;#x27;m delighted that these developers are working on this!</text></item><item><author>pixelmonkey</author><text>The compelling idea here is that they convert the output of common shell commands into tabular data that can be manipulated using common operators, so that you don&amp;#x27;t have the remember sorting&amp;#x2F;filtering&amp;#x2F;grouping flags that may be different for every different shell command. So, imagine being able to use the same sorting&amp;#x2F;filtering logic on the output of `ls` as you might on the output of `ps`, and without relying on hacky solutions like pipelines to `grep`, `cut`, and `sort`.&lt;p&gt;It also means shell command output can be easily transposed into JSON and CSV. Actually pretty clever!</text></item></parent_chain><comment><author>kbenson</author><text>I&amp;#x27;ve generally found you can get most of what you need done with head, tail, grep, cut, paste, sed and tr (and maybe a couple others I&amp;#x27;m missing).  Oh, and test (both bash&amp;#x27;s and coreutil&amp;#x27;s).  It &lt;i&gt;can&lt;/i&gt; be a little hacky, but once you realize the crazy output you sometimes have to parse from third party programs, you realize that the ability to handle any free form text is pretty essential.&lt;p&gt;That said, since I&amp;#x27;m a Perl developer, I&amp;#x27;ll generally just go straight to perl&amp;#x27;s inlined implicit loop mode (-p or -n) if I need to use more than a couple of those utils, unless I want it to be portable with a minimum of requirements (as even though more binaries are used in the shell version, they&amp;#x27;re all essentially guaranteed to exist on a Linux&amp;#x2F;Unix).</text></comment>