BUG: command invocation misinterpreted as variable setting, SOMETIMES.

[Jason Vas Dias]

Good day -

 I am using a fairly up-to-date Cygwin:
   release: cygwin
   arch: x86_64
   setup-timestamp: 1603379981
   include-setup: setup <2.878 not supported
   setup-minimum-version: 2.895
   setup-version: 2.905
 , bash version : 4.4.12(3)-release
 on Windows 10 :
   Edition	Windows 10 Pro
   Version	20H2
   OS build	19042.630
   Experience	Windows Feature Experience Pack 120.2212.31.0
 , which I am forced to use for a work related Visual Studio project,
 , running in a Qemu/KVM VM under Fedora-32 on a modern X86_64 Dell XPS
 laptop, and am experiencing some strange and disconcerting behaviour:

 I am a complete novice Windows user, I have used only BSD / Solaris
 / AIX / HP-UX / MacOSX / z/OS or Linux since 1990, so I am an advanced UNIX
 shell script user & C/C++ + LISP + PERL programmer (I prefer LISP nowadays).

 I have to run a script with an alternate setting of $HOME, so I do:

   $ HOME="C:\\USERS\\JVD\\" sbcl --script "C:\\${path-to-my-script}.lisp"
   
 This works, but now:

   $ cd ~
   -bash: cd: "C:\\USERS\\JVD\\" sbcl --script "C:\\${path-to-my-script}.lisp": No such file or directory
   $ echo $HOME
   /home/JVD

 This is very weird! "$HOME" is still set to its /etc/bash.bashrc set
 default, but evaluation of 'echo ~', which I thought should be
 equivalent to 'echo $HOME', yields the last command to be prefixed
 by a command-specific HOME=... setting .

 I think this is a bug. Since setting HOME=... has no effect now,
 (it still has its correct value),
 use of '~' is now effectively disabled for this shell session .

 What is 'echo ~' doing other than 'echo $HOME' ?

 This is a serious bug to me. I also have some unanswerable questions niggles:
 
 ( where ${path-to-my-script} is the actual name of my script file, not
   an env var.
   SBCL is the Windows build of Steel Bank Common Lisp, installed under
   "C:\\Program\ Files\\", which does not use the Cygwin libraries,
   and accepts Windows style paths as 'native-namestring's , while
   converting pathnames to the 'c:/x/y/z' form with 'namestring'.
   
   Incidentally, can anyone enlighten me as to why a Windows path
   cannot be specified like: "C:\\Program\ Files\ \(x86\)\\" and
   used successfully in Cygwin ?
   Or why a path like that must be specified like:
      /cygdrive/c/Program\ Files\ \(x86\)/...
   on the command line to work in bash completion,  but must be specified like:
      /cygdrive/c/Program Files (x86)/...
   to work in $PATH ? It would be nice to have some consistency here,
   so that scriptlets like the commented out section will work:

function CYGP() # convert windows path to Cygwin path
{  if (( $# < 1 )); then
      echo "$FUNCNAME: expects <windows path list> argument." >&2;
      return 1;
   fi
   declare IFS=';';
   declare -a P=($1);
   declare p='' path='';
   declare -l lcdl;
   unset IFS;
   for p in "${P[@]}"; do
      p="${p//\\//}";
#      while [[ "$p" =~ ^(.*[^\\])?([][[:space:])(}{])(.*)$ ]]; do
#         p="${BASH_REMATCH[1]}\\${BASH_REMATCH[2]}${BASH_REMATCH[3]}";
#      done
#
#     I can't understand why Cygwin can't handle escaped spaces in $PATH, but it can't!
#      
      if [[ "$p" =~ ^([a-zA-Z])[\:](.*)$ ]]; then
         lcdl="${BASH_REMATCH[1]}";
         p="/cygdrive/${lcdl}${BASH_REMATCH[2]}";
      fi
      path="$path${path:+:}$p";
   done
   echo "$path";
}
   It would be nice to be able to uncomment that section in CYGP,
   which does escape all occurences of '[](){}' or [[:space:]]
   correctly, but if used in a $PATH setting, those characters
   cannot be escaped, otherwise that path is not searched. Why?
)
 
  Clarification on the above issues and an eventual fix for them
  would be much appreciated.

  Since I am running Windows under a Linux VM, solutions like
  MSYS2 or Windows Services for Linux (WSL), which seem to
  require one to install a complete Linux distribution under
  Windows, are overkill / sledgehammer approaches for me -
  I don't have the diskspace . Windows & Cygwin installed in only 16GB,
  but Visual Studio consumes @ 50GB, and that's enough Windows
  binaries for me !

  Any advice gratefully received.

Thanks & Best Regards,
Jason