$ find . -name ‘*.blade.php’ -not -path ‘*/vendor/*’ | wc -l

I ran this command a few days ago and all was right with the world.

Running it today I get:

-bash: find .: command not found

Nothing has changed in my system that I'm aware of. A quick search did not return something specific to this problem. Thought it might help someone else to post the question.

What's up with this? :)

  • Check if your PATH variable is correctly set with echo $PATH. – Shaido Nov 7 '17 at 6:20
  • 3
    Is that actually a space between "find" and ".", or something that just looks like one (e.g. a non-breaking space)? – Gordon Davisson Nov 7 '17 at 6:51
  • @Shaido: Fair warning, I'm not a superuser; so, PATH isn't something that feels familiar, might need more detail. – Josh Bruce Nov 7 '17 at 6:56
  • 1
    @JoshBruce No problem, try running echo $PATH and comment with the result here. It should be fairly short. – Shaido Nov 7 '17 at 6:59
  • @GordonDavisson: Fascinating. Took me a second to realize what you were asking. I pasted the original input into Notes. Then copied and pasted back into Terminal. If you explain what happened there in an answer, I will totally accept it. You're awesome! – Josh Bruce Nov 7 '17 at 7:01

I'm not totally certain what happened, but I think you got something like a nonbreaking space between "find" and ".". Nonbreaking spaces are unicode characters that look just like normal spaces, but are intended not to indicate valid places to wrap a line of text. But while they look like normal spaces, the shell has no idea what to do with them, and just treats them like normal characters. One consequence of this is that it doesn't recognize them as delimiters between a command and its argument. Here's an example:

$ find . -name ‘*.blade.php’ -not -path ‘*/vendor/*’ | wc -l    # With normal space
$ find . -name ‘*.blade.php’ -not -path ‘*/vendor/*’ | wc -l    # With nonbreaking space
-bash: find .: command not found
$ find . -name ‘*.blade.php’ -not -path ‘*/vendor/*’ | wc -l    # With ALL nonbreaking spaces
-bash:  wc -l: command not found
-bash: find . -name ‘*.blade.php’ -not -path ‘*/vendor/*’ : No such file or directory

(Note that I don't have any files that match the pattern, so the count comes out 0.) What's happening in the second command is that I have a nonbreaking space (typed as Option-Space on my Mac) between "find" and ".", so the shell treats "find<nonbreakingspace>." as the command... which isn't recognized. In the third command, I replaced ALL spaces with nonbreaking ones; it recognized the "|" as a delimiter between commands, but things literally everything else on the line is part of a command name.

That error message that the command "find ." wasn't found is the giveaway about what's happening; it's treating the space-like-thing and "." as part of the command, so they show up in the error message that way.

On thing confuses me, though: I'm not sure how you got the nonbreaking space there in the first place. Copy-and-paste to & from Notes shouldn't do any conversion. Maybe you bumped Option by mistake? I dunno.

BTW, I noticed another thing while editing this: the single-quotes you have are fancy (curly) unicode ones that look like perfectly good quotes, but like nonbreaking spaces, are not recognized that way by the shell. This one I do know the source of: in many contexts, macOS will auto-"correct" plain quotes to the fancy type (a feature called "smart quotes"). This tends to wreak havoc with scripts. I'll throw in a recommendation for BBEdit as a good editor that doesn't mess with what you enter, making it good for scripting. It's not free, but even if you don't pay it runs in a limited mode that's still much better for scripting than the builtin editors.

  • I don’t know either. The giveaway for me that rich text of some was coming with the paste was that pasting again did magic single quotes not just single prime. I originally copied and pasted from Terminal to Notes, but after the command had run. Maybe Terminal adds something there?? I literally got nothing on how something got there, but it wasn’t just there I don’t think. Even deleting a character at a Time was doing weird things. – Josh Bruce Nov 7 '17 at 7:27
  • Thanks for the tip. Normally I use Sublime Text for all things plain text. Notes is my go to quick storage. Though, if they keep adding fancy features, I might have to reconsider. A markdown editor might suffice to cover the gamut of why I use Notes. – Josh Bruce Nov 7 '17 at 7:30
  • 1
    Deleting character-at-a-time can get weird with unicode if the terminal doesn't realize it's dealing with unicode. In UTF-8 encoded unicode, non-ASCII characters are more than one byte long, and if the terminal doesn't know this it'll delete one byte at a time (i.e. deleting partial characters), leading to complete confusion. – Gordon Davisson Nov 7 '17 at 7:30
  • Thanks. I knew the Unicode byte thing, but had no idea Terminal literally operates a byte at a time. Well done! – Josh Bruce Nov 7 '17 at 7:32
  • 1
    It depends on what character encoding the shell is using. It can treat individual bytes as characters, or Unicode code points as characters (even when one actual character consists of several code points, e.g. base character + combining accents), or... in any case, the real problem is that the shell's idea of a character may be different than the terminal's. – Gordon Davisson Nov 7 '17 at 8:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.