PATCH collides with /usr/bin/patch

[roele]

I'm having issues getting PATCH /some/path to work as it collides with the binary /usr/bin/patch.

Any known workarounds around this issue?

[00dani]

Odd, which shell are you using? I'm on MacOS, which uses case-insensitive filenames, and those commands still aren't colliding for me in Zsh. Perhaps there's case insensitivity in Bash that's mucking things up?

[roele]

Looks like this depends on how the disk is formatted according to http://apple.stackexchange.com/questions/22297/is-bash-in-osx-case-insensitive.

In my case it's standard Mac OS Extended (Journaled) which is case preserving but NOT case sensitive.

[00dani]

Hmm, mine is also Mac OS Extended (Journaled), since I'm told a lot of stuff breaks if you try to use the case sensitive version. So we should be seeing the same behaviour. I just tried loading resty into Bash to see if anything changed, and it still seems to work just fine:

$ source ~/.cache/zsh/zplugin/plugins/micha---resty/resty
$ resty https://httpbin.org
https://httpbin.org*
$ PATCH /patch
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.51.0"
  },
  "json": null,
  "origin": "220.233.83.30",
  "url": "https://httpbin.org/patch"
}
$ patch # this gave an error because i didn't give it a real patch file, but it ran the right program!
aa
patch: **** Only garbage was found in the patch input.

[roele]

The issue reproduces for me no matter what shell i use. It would also clash with TRACE for me.

Are these binaries even available on your system?

$ which patch
/usr/bin/patch
$ which trace
/usr/bin/trace

I'm not sure if these come by default or with the Command Line Tools. It might also worth be mentioning that i use brew with bash and coreutils installed.

[00dani]

Those binaries are definitely available, yep:

$ source ~/.cache/zsh/zplugin/plugins/micha---resty/resty
$ which -a PATCH
/usr/bin/PATCH
$ which -a TRACE
/usr/bin/TRACE
bash-3.2$ resty https://httpbin.org
https://httpbin.org*
bash-3.2$ PATCH /patch
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.51.0"
  },
  "json": null,
  "origin": "220.233.83.30",
  "url": "https://httpbin.org/patch"
}

I guess the which command in Bash doesn't consider shell functions? The functions are still available and work fine though.

Meanwhile, if I do the same thing in Zsh, I can see both the function and command versions.

$ which -a PATCH
PATCH () {
	resty PATCH "$@"
}
/usr/bin/PATCH
$ which -a TRACE
TRACE () {
	resty TRACE "$@"
}
/usr/bin/TRACE
$ PATCH /patch
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.51.0"
  },
  "json": null,
  "origin": "220.233.83.30",
  "url": "https://httpbin.org/patch"
}
$ patch --version
patch 2.5.8
Copyright (C) 1988 Larry Wall
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert

Is it possible that it's just the which command that's giving incorrect info on your system? Does actually invoking PATCH /patch or patch --version work?

[roele]

It's definitely clashing, following command shows the version of /usr/bin/patch instead of the verbose output of a PATCH request.

$ PATCH /patch -v
patch 2.5.8
Copyright (C) 1988 Larry Wall
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Invoking PATCH /patch simply blocks as /usr/bin/patchexpects options.

I also tried following options with no luck

• removing bash, coreutils from brew which resets the bash to the version 3.2
• removing .bash_profile to ensure no setting or other script is causing the behaviour

For now it seems the only way is to resort to plain cURL for these methods.

[roele]

Surprisingly TRACE did not clash and worked as expected which led me to finally diff the latest version of resty with the one on my machine (installed via brew as well). Turns out the PATCH function is not available on the version i use, which explains the behaviour.

Conclusion is that if you install resty via brew ensure to use the HEAD version.
brew install --HEAD resty

Thanks for your help @00dani!