59

I'm facing the next problem in MinGW shell under windows. I have in my /etc/profile the expression:

export GIT_SSH="/c/Program Files/TortoiseGit/bin/TortoisePlink.exe"

This doesn't work when I use git fetch on the local repository. But if I do it like this (old DOS way), it works:

export GIT_SSH="/c/Progra~1/TortoiseGit/bin/TortoisePlink.exe"

My question is:

How can I make it work using spaces in the variable?

For testing purpose you can simulate something like this (any example is good):

export VAR="/c/Program Files/TortoiseGit/bin/TortoisePlink.exe"
# and try to execute like this
$VAR

Is there a solution for this (other than the previous mentioned)?

3
  • 1
    What happens when you try /c/Program\ Files/TortoiseGit/bin/TortoisePlink.exe? That is, include a backslash to escape the space. Commented Apr 28, 2011 at 13:35
  • as suggested below - it is not working Commented Apr 28, 2011 at 13:40
  • @chrisaycock: I was deluded as well, but this would just be a way to avoid the double quotes in the argument of the export command. Afterwards this string is treated in the same way, spaces are still spaces :-) Commented Apr 28, 2011 at 14:08

5 Answers 5

90

Execute it like this: "$VAR". This is one of the most significant gotchas in shell scripting because strings are always substituted literally and any contained spaces are treated as token delimiters rather than as characters of the string. Think of substituting a variable as a kind of code pasting at runtime.

What really happens when you write $VAR is that the shell tries to execute the binary /c/Program with a first argument Files/TortoiseGit/bin/TortoisePlink.exe.

I learned this the hard way by getting a strange syntax error in a big shell script for a particular input. No other languages I can think of can complain for syntax errors if the runtime input contains special characters - but that is the nature of shell scripting since command interpreters like bash and sh interpret the code line by line.

Whenever you expect a string to contain spaces and you don't want to treat it as separate tokens, enclose it in double quotes.

Sign up to request clarification or add additional context in comments.

2 Comments

@Iulian: then you have no other way but to change the other script... or stick without spaces. Git was initially designed for Unix-like operating systems and paths with spaces do not fit their conventions.
If git is calling it without quoting, then it's GIT bug, and should be reported.
16

For reference, I solved a similar issue on osx by encapsulating the argument with escaped quotations. This may not be the best solution, but it seems to work.

alias sub="\"/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl\""

1 Comment

Well it probably only works on osx because it doesn't on linux.
12

I've solved it by including a backslash to escape the space:

/Program Files becomes /Program\ Files

Example:

export GIT_SSH=/c/Program\ Files/TortoiseGit/bin/TortoisePlink.exe

2 Comments

While technically workable, you might get upvotes (instead of downvotes) if you explain what you did. Someone struggling with this isn't going to understand the significance of what you have given.
That's a hack or at best a workaround, not a solution
1

With Git 2.23 (Q3 2019, eight years later), a GIT_SSH set to /c/Program\ Files/TortoiseGit/bin/TortoisePlink.exe will... work (for those still on Windows 7)!

See commit eb7c786 (16 Jul 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit a5194d8, 25 Jul 2019)

mingw: support spawning programs containing spaces in their names

On some older Windows versions (e.g. Windows 7), the CreateProcessW() function does not really support spaces in its first argument, lpApplicationName.
But it supports passing NULL as lpApplicationName, which makes it figure out the application from the (possibly quoted) first argument of lpCommandLine.

Let's use that trick (if we are certain that the first argument matches the executable's path) to support launching programs whose path contains spaces.

This fixes git-for-windows/git issue 692


Git 2.24 (Q4 2019) adds a test:

See commit 71f4960 (01 Oct 2019) by Alexandr Miloslavskiy (SyntevoAlex).
(Merged by Junio C Hamano -- gitster -- in commit 424663d, 09 Oct 2019)

t0061: fix test for argv[0] with spaces (MINGW only)

The test was originally designed for the case where user reported that setting GIT_SSH to a .bat file with spaces in path fails on Windows: git-for-windows#692

Comments

0

some dirty hack for commands with spaces in variables -

for i in `k get po --all-namespaces -o wide | grep 'CrashLoop\|ImagePull' | awk '{printf " -n@%s@scale@deployment/%s",$1,$2}'`; do $(echo "kubectl ${i%-*-*} --replicas=0" | sed 's/@/ /g'); done

so here i use @ instead of space forming variable and use $(echo variavle | sed 's/@/ /g') to execute lines from sed with spaces

It is hackk but it is simplier than all "corect ways" and works for me

Comments

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.