Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There are several issues that can be causing confusion and problems.</p> <ol> <li><p><strong>The Shell Special Variable</strong></p> <p>If <code>core.editor</code> is set to the <em>editor</em> path and filename, then the <code>$*</code> variable is redundant and <em>not</em> needed. However, if the <code>core.editor</code> is set to a shell script, then the <code>$*</code> variable must be passed along to the editor.</p> <p>This is valid:</p> <pre><code>$ git config --global core.editor "'D:/Path To/EditPadPro.exe' //newinstance" </code></pre> <p>This is also valid:</p> <pre><code>$ git config --global core.editor "'E:/Path To/editor.sh'" </code></pre> <p>when editor.sh contains:</p> <pre><code>#!/bin/sh "D:/Path To/EditPadPro.exe" //newinstance "$*" </code></pre></li> <li><p><strong>Spaces in File Names</strong></p> <p>Filenames with spaces can be a pain. If the path/filename is quoted, then it isn't usually a problem. But when setting the value of <code>core.editor</code> you have to either</p> <p>escape the spaces like this:</p> <pre><code>"E:/Path\ To/editor.sh" </code></pre> <p>or quote it twice like this:</p> <pre><code>"'E:/Path To/editor.sh'" </code></pre> <p>Without the extra quotes (or backslash escapes), you will have no problem setting the value, but it will fail when it's used because the outer quotes are not part of the value.</p> <p><strong>EDIT:</strong> Latter method (quoting twice) seems safer. See the edit at the bottom for more explanation.</p></li> <li><p><strong>Windows Path Separator</strong></p> <p>The filename that is being passed to the editor can be a relative path (i.e. .git/COMMIT_EDITMSG) or absolute path (i.e. e:/path to/.git/rebase-merge/git-rebase-todo), but in both cases it is using forward slashes as a path separator. Windows can usually accept forward slashes as a path separator, especially if the path is quoted. Perhaps the <strong>older version of EditPad Pro</strong> is unable to accept the forward slashes in combination with the hidden directory. A little bit of preprocessing can fix this.</p> <p><strong>Note:</strong> Hardcoded paths with forward slashes and <em>no</em> hidden directory seem to work fine. Hardcoded paths with hidden directories <em>and</em> backslashes seem to work fine.</p></li> </ol> <h2>Final Solution</h2> <p>I'm not very experienced with shell scripting, but the following is now working for me.</p> <p>The editor.sh file contains:</p> <pre><code>#!/bin/sh fullpath=`echo "$*" | tr '/' '\\\'` "D:/Program Files/JGsoft/EditPadPro5/EditPadPro.exe" //newinstance "$fullpath" </code></pre> <p>and the config is set like this:</p> <pre><code>$ git config --global core.editor "'E:/Path To/editor.sh'" </code></pre> <p>My copy of EditPad Pro 5.3.2 is now opening with the correct files already loaded, regardless of what git command launches the editor.</p> <p><strong>EDIT:</strong> I had to change the value of <code>core.editor</code>. I had used backslashes to escape spaces in the path and this opened the editor properly. However, when a GIt command passed a fielname with a relative path (beginning with a dot) to my shell script, the value of <code>$*</code> was <em>$@</em> rather than the filename, which caused the editor to open with a blank file named <em>$@</em>. I thought I tested that combination, but apparently not. Using the <em>quote twice</em> method works.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload