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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
