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

[Andrey Repin <anrdaemon@yandex.ru>]

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