Per the Magento download page, under the patches section

Please upload the patch into your Magento root directory and run the appropriate SSH command: For patch files with the file extension `.sh: sh patch_file_name.sh Example: sh PATCH_SUPEE-1868_CE_1.7.0.2_v1.sh

Magento recommends a direct invocation of the sh command to run their patch runner. The file extension of .sh supports this as well.

However, if you look at the top of each patch runner file, the shebang line points to bash.

# Patch apllying tool template
# v0.1.2
# (c) Copyright 2013. Magento Inc.

The programmer in me wants to trust the source file, but the process wonk wants to obey what's written on the Magento website, the cynic wonders if the patch has been tested against the differences between bash and sh.

  • The patch process should be as simple as .diff files zipped up. REQUIRED_UTILS='sed patch' all I see in the .sh scripts. The upgrading docs for recent versions reads like stereo instructions, and upgrading shouldn't be that painful.
    – B00MER
    Jan 22, 2014 at 23:44
  • 2
    I somewhat blindly fetch the patch, chmod +x and run it . (Well I check the contents first) but I run it locally (Mac based dev) so I can git branch and commit to a test branch before deploy. Jan 22, 2014 at 23:45
  • 3
    @B00MER That's tricky. I agree personally, but for tech savvy but not unix savvy people manually applying patches seems like a step too far. I can understand the motivations behind a patch installer. Jan 22, 2014 at 23:50
  • Just thinking about this again. The shebang lins could be #!/bin/php for example and, sh executes "enough" to read the shebang line and pass the script to the shebang'ed program. On the subject of manual applies, the patch contains the Git Diffs anyway, so you can "easily" apply yourself. But, is there an argument to ask Magento to provide a zip with changed files in only, along side a Patch (which is fine except for Core edits)? Jan 23, 2014 at 8:30
  • One more thing. The use of a file extension, other than .txt probably makes it more logical for the less savvy, to avoid having extensionless files floating about the local users file system. I feel bash and sh are interchangeable anyway. Jan 23, 2014 at 8:37

2 Answers 2


You must use bash, actually. On line 14 of the patch you explicitly pointed out is this code:

if (( $? != 0 )); then

$(( is a valid arithmetic expression in XCU sh, but (( is not.)

On many UNIX-like platforms, however, /bin/sh is just a symlink to /bin/bash. When invoked with the name sh, bash does disable some of its POSIXly-unstrict behavior, but not all of it. It's likely that these patches would work fine for bash invoked as sh.

  • In this case tho, the script isn't executing under sh, sh is dumping off to the stated shebang line program? Jan 23, 2014 at 8:33
  • Actually the kernel is responsible for interpreting the shebang. If you chmod +x script && ./script the kernel will attempt to execute the command in the shebang line with the script file as its first or second argument. Depending on the circumstances, there's no guarantee that any shell is involved in that process tree. If you execute sh with a script as its argument, however, the shebang line will be ignored.
    – kojiro
    Jan 23, 2014 at 11:58
  • So that means I'm following the patch instructions wrong. As they say do sh script but I just do ./script How amusing Jan 23, 2014 at 20:49

In case it helps someone in future, I have used Phpstorm to apply patch and its patch tool is great. It took less than 30 seconds to apply patch without any issues and you can also see and go through the differences the files have.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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