BUG: command invocation misinterpreted as variable setting, SOMETIMES.

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



 

 



   

Re: BUG: command invocation misinterpreted as variable setting, SOMETIMES.

[Duncan Roe]

Hi Jason,

On Fri, Nov 20, 2020 at 02:52:09PM +0000, cygwin wrote:
>
> 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' ?

If you had tried 'set -x' you would have seen what it does: tilde expansion is
done by bash before the echo command is invoked. So you would see something like
'echo /home/jvd'.

Could it be that 'sbcl' has popped a new bash command level?

I can't reproduce your issue with a simple command instead of 'sbcl' e.g.

> 09:33:42$ HOME="C:\\USERS\\DUNCAN\\" pwd
> /home/dunc
> 09:34:02$ echo ~
> /home/dunc
>
[...]
>
Cheers ... Duncan.

Re: BUG: command invocation misinterpreted as variable setting, SOMETIMES.

[Andrey Repin]

Greetings, Jason Vas Dias!

>  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"

You should use Cygwin (POSIX) style paths here. (assuming sbcl is a Cygwin
program)
Also, trailing path separator is unnecessary, if not confusing.

>  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 .

The first thing in debugging is to understand that computers are essentially
stupid. They do exactly what you ask them to.

>  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' ?

Nothing, I'm unable to reproduce your behavior.

>  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,

Then you are doing it wrong.
Cygwin is not supposed to understand Windows paths, although in many cases it
does.

>    and accepts Windows style paths as 'native-namestring's , while
>    converting pathnames to the 'c:/x/y/z' form with 'namestring'.

These are same paths, Windows don't see a difference between \ and / as path
separators. Since DOS 3.3 at least.

>    Incidentally, can anyone enlighten me as to why a Windows path
>    cannot be specified like: "C:\\Program\ Files\ \(x86\)\\" and
>    used successfully in Cygwin ?

It could, in a small set of cases. However, in general it's not supposed to,
see above.

>    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:

This:

> 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

>   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 !

MSYS2 is a Cygwin spin-off, not a "complete linux distribution".

>   Any advice gratefully received.

You have a choice between using Cygwin-provided clisp (An ANSI Common LISP
implementation), building LISP of your choice under Cygwin, dealing with path
differencies on your own or not using Cygwin.
Depends, what you are using Cygwin for. From the sound of it, you don't need
Cygwin at all to begin with.


-- 
With best regards,
Andrey Repin
Saturday, November 21, 2020 12:22:45

Sorry for my terrible english...