>>>>>>>> Does anyone know the rational with this behaviour and what can be
>>>>>>>> done to get hold of the (real) Windows TMP/TEMP
>>>>>>>> environment-variable-values (in a
>>>>>>>> (hopefully) platform independent way) ?
>>>>>>> so if you are making your custom tree, try to stick on that
>>>>>>> expectation and have both directories.
>>>>>> In general, you are free to set TMP to a directory of your choice,
>>>>>> that's the purpose of that variable, no need to sync it with some root.
>>>>>> There is a comment in /etc/profile:
>>>>>> # TMP and TEMP as defined in the Windows environment
>>>>>> # can have unexpected consequences for cygwin apps, but it does not
>>>>>> explain what consequences that might be; probably some trouble with
>>>>>> ACL/access permissions for temporary files.
>>>>> Nowadays that would be $LOCALAPPDATA/Temp, or if you really insist, the
>>>>> content of /proc/registry/HKEY_CURRENT_USER/Environment/TMP (or TEMP),
>>>>> after similarly expanding environment variable references found in that.
>>>>>
>>>>> The fact that getting Windows' idea of the user's TEMP directory is not
>>>>> immediately platform independent may well have been part of the rationale
>>>>> for not even trying that.
>>>>
>>>> Well, at least it's up to the user
>>>>
>>>> If the user sets its TMP-variable to "C:\Jabba Dabba Dooo" or "/jabba
>>>> dabba doo", I expect the value of getenv("TMP") should be just that and
>>>> regardless of OS the value returned is whatever the variable is set to and
>>>> not magically changed to "/tmp"
>>> Of course and that's not happening, no worries. The issue was that TMP is
>>> set in /etc/profile and not inherited from the Windows environment.
>> Well, where my Cygwin-compiled-application is running, there’s no
>> Cygwin-installation and thus no /etc/profile so it cannot be set there (if
>> /etc/profile is not a built in resource in every executable), so there must
>> be some text-value inside the compiled executables used in some manner
>> somehow
>
> There must be something going on in your environment that you haven't told us
> yet. I just tried the following test case:
>
> #include <stdio.h>
> #include <stdlib.h>
> int
> main ()
> {
> printf ("The value of TMP is %s\n", getenv ("TMP"));
> }
>
> In a Cygwin bash shell I get
>
> The value of TMP is /tmp
>
> Running the same executable under a Windows Command Prompt, I get
>
> The value of TMP is /c/Users/kbrown/AppData/Local/Temp
>
> So Cygwin converts TMP to a Posix path [*], but it doesn't change it to
> "/tmp".
>
> Ken
>
> [*] See environ.cc:303 for a list of environment variables that Cygwin
> converts.
Hmm, you’re right Ken
I tried this before taking off for a vacation and the Windows-TMP-variable is
extracted
I now suspect that we maybe do have some logic that falls back to /tmp if the
TMP-variable is NULL and perhaps the variable is NULL because we launch the
process with CreateProcess and perhaps the environment-variables doesn’t get
inherited then ?
The reason why we use CreateProcess from within a cygwin-application to create
another cygwin-application (instead of fork or such) might seem weird, but it
has its reasons
I need to confirm this after the vacation-trip or if someone already know if
environment-variables “dissapear” if things such as CreateProcess are used ?
Best regards,
Kristian
--
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
