this is a special interpretation added by the shell, and programs don't actually see the ''s. If you put a '' next to other non-whitespace characters, it disappears in the command line that the program will see.

I object to the notion that this is a special interpretation. The author is just misunderstanding the general case of how shells parse commands.

In most shells, you can concatenate strings by placing them directly next to one another. Ie, this forms one string containing the word foobarbaz:

    foo"bar"'baz'

This is useful because different types of quotation marks have different semantics. Eg, double quotes are interpolating while single quotes are not. You might want to mix interpolated portions and non-interpolated portions into a single argument or assignment.

Shell is also famously stringly-typed. All parameters passed to a command (and indeed, even the command itself) are separate strings. So indeed, the final find command from this blog post could also be written as:

    "read" "-r" "-d"'' "line"

Then the error becomes clear.

This is an important thing to understand if you're going to write any non-trivial amount of shell, especially if you're using a shell variant that opportunistically wordsplits (like POSIX sh or Bash, as opposed to Zsh).

As an aside, this is also an example of why it's good to keep a consistent and clean style, and not unnecessarily shorten in every circumstance where you could get away with it. Mashing command line parameters together makes them a lot less readable, and is meant more as a convenience for interactive usage, than for writing scripts meant to be read and expanded upon later.

    cut -d' '

    cut '-d '

> then I've done the standard thing of removing the space between -d and its argument

That's not standard, although it is (sometimes) allowed. What it also is, though, is dumb, and people shouldn't do it.

It's on par with Windows folks going out of their way to use backslash for path separator in instances where a plain ol' slash will do—just because the sheer idiosyncratic obscurantism gives them delight. A couple years ago I noticed that in between the original introduction of PowerShell, which deliberately settled on using slash for file path separators, and the present day, some doofuses went out of their way to not only insist on backslash as the suggested separator, but they changed how Tab-for-autocomplete works so that existing slashes in paths written on the command line will be "fixed" and converted into backslashes. Whoever is responsible for this should never be allowed to touch user-facing software ever again.

re: the last few paragraphs, bash strings can't contain NUL either. `$'\0'` isn't distinguishable from `''`. For example `<<< $'\0' xxd` and `<<< '' xxd` both connect an empty string (plus newline) to xxd's stdin.

Oh my...

I'm pretty sure I already ran into this due some pedantic shellcheck rules telling me I should use `read` for some array construction, and when I realized it doesn't work the way I want it to, would probably silence the warning and go on.

First thing Monday, grepping for all my shell scripts for this.

Related part of IEEE Std 1003.1: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1..., Guideline 6

Using bash builtins and not binutils introduces some quirks of how globbing, IFS and $var expansion interacts. I tend to prefer worked examples use Bourne shell and are explicit about builtins vs bin utils.

My favorite commands to accidentally add extra spaces to usually involve 'rm' and 'sudo'.