Unix Wildcards Gone Wild (2014)
This, plus the problem of dealing with files with spaces, newlines, tabs, etc. in their names, are what draw the line for me between &quot;things I am willing to write as a shell script&quot; and &quot;things that will make me use a scripting language† with its own file-manipulation system-call builtins.&quot;<p>A three-line script that takes one file as an argument? Sure, write that in bash.<p>A script that processes N files passed as arguments? Or that processes a <i>listing</i> of files piped in from stdin? And uses branching logic on the files themselves? Bash goes out the window.<p>Sure, it&#x27;s <i>possible</i> to write shell scripts to do that. But why? Unless you&#x27;re targeting a PDP11 or the Busybox-linked &#x2F;bin&#x2F;sh in your initramfs, is shell scripting really the <i>best</i> option?<p>---<p>† Personally, I reach for Ruby in these cases; its stdlib Pathname and FileUtils classes are pretty solid for this use-case, and Ruby interpreters are now roughly everywhere I want to deploy.<p>Ruby <i>is</i> kind of clumsy for doing all the command piping parts of scripting, though; especially since there&#x27;s no easy way short of wrapping Kernel.system in your own function to make a Ruby script crash on a nonzero subshell exit status.<p>I&#x27;d love to know if there was a language that was like Ruby in terms of the syntax and semantics around strings, arrays, and files; but then was &quot;just like writing a shell script&quot; in the sense of being able to just use binary names to make &quot;function calls&quot; that are really synchronous subshell spawns and exit-code checks in one (but which still use the variable-passing semantics of the language where the resulting exec(2) ARGV is concerned.) Probably a Ruby DSL is the simplest way to get that—but if it&#x27;s not in the stdlib, I&#x27;m not going to be able to use it for DevOps scripting :&#x2F;