What’s the difference between $(…) and `…` in Bash

This is a synthesis from my longer answer to a similar question in SO.

If your app logs to stdout/stderr, use:

cmd //c start cmd //k  "path\\to\\script-dir\\script.py"

If it logs to files, via sockets etc. and you do not need stdout/stderr, use:

cmd //c start //D "path\\to\\script-dir" script.py

In both cases you get a daemon like process which will survive when you close bash. In the first instance your script is hosted in a visible cmd.exe window.

Much more here.

Different approach:

When you run git log --format="foo bar", those quotes aren't interpreted by git – they're removed by the shell (and protect the quoted text from splitting). This results in a single arg:

• --format=foo bar

However, when unquoted variables are expanded, the results go through word-splitting, but not through unquoting. So if your variable contains --format="foo bar", it is expanded into these args:

• --format="foo
• bar"

This can be verified using:

• printf '%s\n' $variable

...as well as any simple script which prints its received arguments.

• #!/usr/bin/env perl
  for $i (0..$#ARGV) {
      print ($i+1)." = ".$ARGV[$i]."\n";
  }
  

• #!/usr/bin/env python3
  import sys
  for i, arg in enumerate(sys.argv):
      print(i, "=", arg)
  

If you always have bash available, the preferred workaround is to use array variables:

myvar=( --format="foo bar" )

With this, the usual parsing is done during assignment, not during expansion. You use this syntax to expand the variable's contents, each element getting its own arg:

git log "${myvar[@]}"