* Re: Cygwin convert environment paths
2020-05-10 12:42 Cygwin convert environment paths Steven Penny
2020-05-10 15:06 ` Achim Gratz
@ 2020-05-10 17:52 ` Doug Henderson
2020-05-12 19:18 ` Andrey Repin
2 siblings, 0 replies; 7+ messages in thread
From: Doug Henderson @ 2020-05-10 17:52 UTC (permalink / raw)
To: cygwin
On Sun, 10 May 2020 at 06:46, Steven Penny via Cygwin <> wrote:
> <snip>
> That Cygwin does convert some environment variables, from Windows format to
> Unix format. For example HOME and TMP. But for me at least, are some
> important
> omissions.
>
<snip>
>
In general, converting environment variable owned by Windows to cygwin
format is a very bad idea. These are the variables that are present in
cmd.exe in a vanilla Windows install. The only exception is the PATH
variable.
Personally, I always set CYGWIN_NOWINPATH=1 in the system environment
variables to avoid accidentally calling a windows program while in cygwin.
Every time I want to call a windows program from cygwin, I explicitly use
its full path. Or I have create and use a shell alias that contains that
full path.
There is no problem with HOME and TMP (and a few others like TEMP,
BROWSER, EDITOR, INFOPATH, PWD, SHELL), because these are not normally set
in the Windows environment, or during the execution of cmd.exe. (I can't
comment on powershell, as I don't use it.)
I experimented with using cygpath to pre-convert several variables that
have windows paths, or windows path lists in order to interchangeably run
the cygwin version and a windows version of the same application, and to
spawn windows programs from cygwin programs and cygwin programs from
windows programs. I failed to create an environment that worked for both
types of programs at the same time.
What I found to partially work for interchangeability was to wrap the
cygwin program in a bash script to perform environment conversions, This
failed, though, when the cygwin program spawned a windows program which, of
course, expected windows paths and path lists in its environment. I also
tried wrapping the windows programs with similar conversion,
An alternate approach, that worked for my own cygwin code was to create
variables like CYG_HOMEDRIVE, or WIN_HOME. But this introduces a different
set of problems.
I also tried a couple of mingw64 installations: the standard one, and the
one packaged with Git for Windows. Programs from those projects tended to
work in the windows environment, but allowed you to use linux style file
names directly.
I did not try mixing cygwin and mingg64 programs.
My conclusion was that there is no universal way to make unmodified
programs work in the alternate environment.
In the OP's specific case of using HOMEDRIVE, he must accept that this is a
variable "owned" by windows, and thus not found in the linux environment.
Any code that is meant to execute in both cygwin and linux must have code
paths for each. And a cygwin program that wants to use a Windows variable,
must perform its own conversions, either manually or using cygpath. As I
understand it, the cygpath program is a thin wrapper over a library call,
so a CFFI (C Foreign Function Interface) might work.
HTH
Doug
--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin convert environment paths
2020-05-10 12:42 Cygwin convert environment paths Steven Penny
2020-05-10 15:06 ` Achim Gratz
2020-05-10 17:52 ` Doug Henderson
@ 2020-05-12 19:18 ` Andrey Repin
2 siblings, 0 replies; 7+ messages in thread
From: Andrey Repin @ 2020-05-12 19:18 UTC (permalink / raw)
To: Steven Penny, cygwin
Greetings, Steven Penny!
> I see here:
> <https://cygwin.com/cygwin-ug-net/setup-env.html>
> That Cygwin does convert some environment variables, from Windows format to
> Unix format. For example HOME and TMP. But for me at least, are some important
> omissions.
> I use APPDATA and PROGRAMFILES a good amount, and those arent converted. To make
> it worse, HOMEDRIVE and SYSTEMDRIVE arent converted either, meaning you cant
> manually construct the path starting with a variable. This causes some
> problems. Take this example:
These are not making any sense for Cygwin itself, so they are left alone.
> <?php
> $s_old = realpath('a.txt');
> $s_new = getenv('HOMEDRIVE') . DIRECTORY_SEPARATOR . 'a.txt';
> # PHP Warning: symlink(): No such file or directory
> symlink($s_old, $s_new);
Use native php ?…
--
With best regards,
Andrey Repin
Tuesday, May 12, 2020 22:17:30
Sorry for my terrible english...
^ permalink raw reply [flat|nested] 7+ messages in thread