On 2020-09-17 23:56, Kristian Ivarsson via Cygwin wrote:
>
>>>>>>>>> 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 ?
Programmer optional - same applies for CreateProcessA/W/AsUserA/W:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
"lpEnvironment
A pointer to the environment block for the new process. If this parameter is
NULL, the new process uses the environment of the calling process.
An environment block consists of a null-terminated block of null-terminated
strings. Each string is in the following form:
name=value\0
Because the equal sign is used as a separator, it must not be used in the name
of an environment variable.
An environment block can contain either Unicode or ANSI characters. If the
environment block pointed to by lpEnvironment contains Unicode characters, be
sure that dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT. If this parameter
is NULL and the environment block of the parent process contains Unicode
characters, you must also ensure that dwCreationFlags includes
CREATE_UNICODE_ENVIRONMENT.
The ANSI version of this function, CreateProcessA fails if the total size of the
environment block for the process exceeds 32,767 characters.
Note that an ANSI environment block is terminated by two zero bytes: one for the
last string, one more to terminate the block. A Unicode environment block is
terminated by four zero bytes: two for the last string, two more to terminate
the block."
Note that when MS say "Unicode" they usually mean UTF16LE, which only some
programs support, depending on the I/O functions they use.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
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
