<story><title>You shouldn&apos;t parse the output of ls(1)</title><url>https://mywiki.wooledge.org/ParsingLs</url></story><parent_chain></parent_chain><comment><author>salmo</author><text>Some of these are why I bail for a “real language” in many seemingly simple scenarios.&lt;p&gt;As soon as I care about datetimes, it’s just easier to use stat() and a proper datetime API.&lt;p&gt;I can treat filenames as byte arrays and translate to Unicode or let the language do it for me.&lt;p&gt;In dire circumstances, find … -print0 | xargs -0 second_script is usually my fallback, but that has pitfalls as well.&lt;p&gt;Go has been a blessing there for me, not having to rely on a runtime across diverse hosts. But that’s a preference and doesn’t help on old kernels w&amp;#x2F;o epoll().&lt;p&gt;So many battle scars from inconsistency in Bash and GNU utilities over the years, especially on Unixes’ bundled versions (Solaris, etc) or supporting GNU, BSD, SysV, and HP-UX in the same script.  Used to deploy a ksh88(ish) on all for SOME consistency.&lt;p&gt;Luckily now I’m not supporting anything but Linux anymore.  When I can’t Go, then I just hijack some tool’s bundled Ruby (eg Puppet), Python, etc when I have to handle that and stick to the standard library.&lt;p&gt;I am too lazy to C these days like I used to.  I’m usually dealing with an emergency (looking at you log4j) and don’t have the cycles to cover the gotchas there.</text></comment>
<story><title>You shouldn&apos;t parse the output of ls(1)</title><url>https://mywiki.wooledge.org/ParsingLs</url></story><parent_chain></parent_chain><comment><author>tyingq</author><text>This is one reason Perl was very popular even before CGI was a thing.  You could get to things like stat() with an interpreted language that was very portable.  It also has the &amp;quot;-0&amp;quot; flag to accept the null terminated output of &amp;quot;find -print0&amp;quot;.</text></comment>