TMP/TEMP environment variable and /tmp

TMP/TEMP environment variable and /tmp

[sten.kristian.ivarsson]

Dear folks

Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
and sets them to /tmp for cygwin-built-applications (executables) ?

This results in that when you want the current users TMP-folder you end up
with the /tmp path. As a result,when writing to that, without having cygwin
installed (e.g. C:\cygwin64\), it seems like it refers to ${CWD}/../tmp/ and
that is not always accessible by all users 


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


Best regards,
Kristian

Re: TMP/TEMP environment variable and /tmp

[marco atzeri]

On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
<cygwin@cygwin.com> wrote:
>
> Dear folks
>
> Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
> and sets them to /tmp for cygwin-built-applications (executables) ?
>
> This results in that when you want the current users TMP-folder you end up
> with the /tmp path. As a result,when writing to that, without having cygwin
> installed (e.g. C:\cygwin64\), it seems like it refers to ${CWD}/../tmp/ and
> that is not always accessible by all users
>
>
> 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) ?
>
>
> Best regards,
> Kristian
>

the logic behind is that the program should be located
in
    $YOUR_ROOT/bin

and the temp will be
    $YOUR_ROOT/tmp

so if you are making your custom tree, try to stick on that expectation
and have both directories.

Re: TMP/TEMP environment variable and /tmp

[Thomas Wolff]

Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin:
> On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
> <cygwin@cygwin.com> wrote:
>> Dear folks
>>
>> Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
>> and sets them to /tmp for cygwin-built-applications (executables) ?
>>
>> This results in that when you want the current users TMP-folder you end up
>> with the /tmp path. As a result,when writing to that, without having cygwin
>> installed (e.g. C:\cygwin64\), it seems like it refers to ${CWD}/../tmp/ and
>> that is not always accessible by all users
>>
>>
>> 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) ?
>>
>>
>> Best regards,
>> Kristian
>>
> the logic behind is that the program should be located
> in
>      $YOUR_ROOT/bin
>
> and the temp will be
>      $YOUR_ROOT/tmp
>
> 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.
Thomas

Re: TMP/TEMP environment variable and /tmp

[Hans-Bernhard Bröker]

Am 16.09.2020 um 13:12 schrieb Thomas Wolff:
> Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin:
>> On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin

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

A bigger part of the reason may have been what the result of that 
platform-dependent query would have been, back when the decision had to 
be made.  For several releases you would have ended up with (your 
locally translated version of!) stupid old "Documents and Settings" as 
part of the pathname, and possibly some extra blanks and special 
characters from the user name, on top of that.

And I for one really do not trust that a Unix temp directory can safely 
have white space in its name without breaking lots of tools' behavior in 
nastily interesting ways.  IIRC it took until Windows 8 for Microsoft to 
finally own up to their error and change it to the profoundly less 
insane "Users".  But by then it was too late, all the damage had been 
done already.

Sv: TMP/TEMP environment variable and /tmp

[sten.kristian.ivarsson]

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


Best regards,
Kristian

[snip]

Re: Sv: TMP/TEMP environment variable and /tmp

[Thomas Wolff]

Am 17.09.2020 um 14:12 schrieb Kristian Ivarsson via Cygwin:
>>>>> 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.

Re: TMP/TEMP environment variable and /tmp

[Ken Brown]

On 9/16/2020 7:12 AM, Thomas Wolff wrote:
> Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin:
>> On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
>> <cygwin@cygwin.com> wrote:
>>> Dear folks
>>>
>>> Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s)
>>> and sets them to /tmp for cygwin-built-applications (executables) ?
>>>
>>> This results in that when you want the current users TMP-folder you end up
>>> with the /tmp path. As a result,when writing to that, without having cygwin
>>> installed (e.g. C:\cygwin64\), it seems like it refers to ${CWD}/../tmp/ and
>>> that is not always accessible by all users
>>>
>>>
>>> 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) ?
>>>
>>>
>>> Best regards,
>>> Kristian
>>>
>> the logic behind is that the program should be located
>> in
>>      $YOUR_ROOT/bin
>>
>> and the temp will be
>>      $YOUR_ROOT/tmp
>>
>> 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.

That's right.  There was an issue in 2009 in which 'patch' was unexpectedly 
changing permissions.  See the long thread starting at

   https://cygwin.com/pipermail/cygwin/2009-November/181760.html

and continuing at

   https://sourceware.org/pipermail/cygwin/2009-December/181829.html

The problem was caused by the inheritable permissions on a temporary directory 
that patch was using, based on the value of the Windows TMP environment variable.

Ken

Re: TMP/TEMP environment variable and /tmp

[Kristian Ivarsson]

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

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

Re: TMP/TEMP environment variable and /tmp

[Ken Brown]

On 9/17/2020 5:07 PM, 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.

Re: TMP/TEMP environment variable and /tmp

[Doug Henderson]

On Thu, 17 Sep 2020 at 15:56, Ken Brown via Cygwin <> wrote:
>

#include <stdio.h>
#include <stdlib.h>
int
main ()
{
    char *temp_nam;
    char *p_tmp_nam;

    printf ("$TMP      is '%s'\n", getenv ("TMP"));
    printf ("$TMPDIR   is '%s'\n", getenv ("TMPDIR"));
    printf ("$TEMP     is '%s'\n", getenv ("TEMP"));
    printf ("P_tmpdir  is '%s'\n", P_tmpdir);
    p_tmp_nam = tmpnam(0);
    printf ("tmpnam()  is '%s'\n", p_tmp_nam);
    temp_nam = tempnam(0, 0);
    printf ("tempnam() is '%s'\n", temp_nam);
    free(temp_nam);
}


# start a new shell
$ sh
$ TMP= TEMP= ./show_tmp
$TMP      is ''
$TMPDIR   is '(null)'
$TEMP     is ''
P_tmpdir  is '/tmp'
tmpnam()  is '/tmp/t707.0'
tempnam() is '/tmp/ffffd187.2'

# start cmd.exe
$ /cygdrive/c/windows/system32/cmd.exe
Microsoft Windows [Version 10.0.18363.1082]
(c) 2019 Microsoft Corporation. All rights reserved.
>set TMP=
>set TEMP=
> show_tmp
$TMP      is '(null)'
$TMPDIR   is '(null)'
$TEMP     is '(null)'
P_tmpdir  is '/tmp'
tmpnam()  is '/tmp/t709.0'
tempnam() is '/tmp/ffffd189.2'

P_tmpdir is defined in <stdio.h>


-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

Re: TMP/TEMP environment variable and /tmp

[Ken Brown]

On 9/17/2020 7:58 PM, Doug Henderson via Cygwin wrote:
> On Thu, 17 Sep 2020 at 15:56, Ken Brown via Cygwin <> wrote:
>>
> 
> #include <stdio.h>
> #include <stdlib.h>
> int
> main ()
> {
>      char *temp_nam;
>      char *p_tmp_nam;
> 
>      printf ("$TMP      is '%s'\n", getenv ("TMP"));
>      printf ("$TMPDIR   is '%s'\n", getenv ("TMPDIR"));
>      printf ("$TEMP     is '%s'\n", getenv ("TEMP"));
>      printf ("P_tmpdir  is '%s'\n", P_tmpdir);
>      p_tmp_nam = tmpnam(0);
>      printf ("tmpnam()  is '%s'\n", p_tmp_nam);
>      temp_nam = tempnam(0, 0);
>      printf ("tempnam() is '%s'\n", temp_nam);
>      free(temp_nam);
> }
> 
> 
> # start a new shell
> $ sh
> $ TMP= TEMP= ./show_tmp
> $TMP      is ''
> $TMPDIR   is '(null)'
> $TEMP     is ''
> P_tmpdir  is '/tmp'
> tmpnam()  is '/tmp/t707.0'
> tempnam() is '/tmp/ffffd187.2'
> 
> # start cmd.exe
> $ /cygdrive/c/windows/system32/cmd.exe
> Microsoft Windows [Version 10.0.18363.1082]
> (c) 2019 Microsoft Corporation. All rights reserved.
>> set TMP=
>> set TEMP=
>> show_tmp
> $TMP      is '(null)'
> $TMPDIR   is '(null)'
> $TEMP     is '(null)'
> P_tmpdir  is '/tmp'
> tmpnam()  is '/tmp/t709.0'
> tempnam() is '/tmp/ffffd189.2'
> 
> P_tmpdir is defined in <stdio.h>

Sorry, but I'm missing your point.  How is this related to Kristian's claim that 
Cygwin is changing the value of the TMP environment variable to "/tmp"?

Ken

Re: TMP/TEMP environment variable and /tmp

[Brian Inglis]

On 2020-09-17 20:17, Ken Brown via Cygwin wrote:
> On 9/17/2020 7:58 PM, Doug Henderson via Cygwin wrote:
>> On Thu, 17 Sep 2020 at 15:56, Ken Brown via Cygwin <> wrote:
>>>
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> int
>> main ()
>> {
>>      char *temp_nam;
>>      char *p_tmp_nam;
>>
>>      printf ("$TMP      is '%s'\n", getenv ("TMP"));
>>      printf ("$TMPDIR   is '%s'\n", getenv ("TMPDIR"));
>>      printf ("$TEMP     is '%s'\n", getenv ("TEMP"));
>>      printf ("P_tmpdir  is '%s'\n", P_tmpdir);
>>      p_tmp_nam = tmpnam(0);
>>      printf ("tmpnam()  is '%s'\n", p_tmp_nam);
>>      temp_nam = tempnam(0, 0);
>>      printf ("tempnam() is '%s'\n", temp_nam);
>>      free(temp_nam);
>> }
>>
>>
>> # start a new shell
>> $ sh
>> $ TMP= TEMP= ./show_tmp
>> $TMP      is ''
>> $TMPDIR   is '(null)'
>> $TEMP     is ''
>> P_tmpdir  is '/tmp'
>> tmpnam()  is '/tmp/t707.0'
>> tempnam() is '/tmp/ffffd187.2'
>>
>> # start cmd.exe
>> $ /cygdrive/c/windows/system32/cmd.exe
>> Microsoft Windows [Version 10.0.18363.1082]
>> (c) 2019 Microsoft Corporation. All rights reserved.
>>> set TMP=
>>> set TEMP=
>>> show_tmp
>> $TMP      is '(null)'
>> $TMPDIR   is '(null)'
>> $TEMP     is '(null)'
>> P_tmpdir  is '/tmp'
>> tmpnam()  is '/tmp/t709.0'
>> tempnam() is '/tmp/ffffd189.2'
>>
>> P_tmpdir is defined in <stdio.h>
> 
> Sorry, but I'm missing your point.  How is this related to Kristian's claim that
> Cygwin is changing the value of the TMP environment variable to "/tmp"?

It demonstrates that Cygwin programs don't themselves change TEMP/TMP, unless
they call an API routine that generates a filename in a directory, when the
filesystem handling may translate a nonexistent or unmounted /tmp/ to ../tmp/.

That jives with the defaults I see in the registry and in the cmd environments:

$ regtool list -v
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session\
Manager/Environment | grep 'T.*MP'
TEMP (REG_EXPAND_SZ) = "%SystemRoot%\TEMP"
TMP (REG_EXPAND_SZ) = "%SystemRoot%\TEMP"

$ regtool list -v /proc/registry/HKEY_CURRENT_USER/Environment | grep 'T.*MP'
TEMP (REG_EXPAND_SZ) = "%UserProfile%\AppData\Local\TEMP"
TMP (REG_EXPAND_SZ) = "%UserProfile%\AppData\Local\TEMP"

C:\Windows\system32>set | grep "T.*MP"
TEMP=C:\Windows\TEMP
TMP=C:\Windows\TEMP
C:\Windows\system32>which env
/usr/bin/env
C:\Windows\system32>env | grep "T.*MP"
TEMP=/cygdrive/c/Windows/TEMP
TMP=/cygdrive/c/Windows/TEMP

C:\Users\...>set | grep "T.*MP"
TEMP=C:\Users\...\AppData\Local\Temp
TMP=C:\Users\...\AppData\Local\Temp
C:\Users\...>env | grep "T.*MP"
TEMP=/cygdrive/c/Users/.../AppData/Local/Temp
TMP=/cygdrive/c/Users/.../AppData/Local/Temp

and I know you can just delete those environment variables and registry keys at
the risk of upsetting any Windows programs that need temp space and do not
provide an accessible fallback.

The same goes for any Cygwin script or program: each application needs to check
it has access to any output locations: the directory is writable and the file
can be created e.g. in /var/log/ or /tmp/, or try to create a directory, or try
elsewhere /usr/tmp/, /var/tmp/, or create that, or try the current directory ./
or home directory $HOME/, known paths $USERPROFILE/ or $LOCALAPPDATA/Temp/, or
exit with a failure condition.

I think we need to see the environment or registry and application code around
creating the file to diagnose the cause, but I expect the environment may not
define TMPDIR/TMP/TEMP, the application provides no accessible fallback(s), and
Cygwin defaults the path.

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

Re: TMP/TEMP environment variable and /tmp

[Kristian Ivarsson]

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

Re: TMP/TEMP environment variable and /tmp

[Brian Inglis]

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

Re: Sv: TMP/TEMP environment variable and /tmp

[Andrey Repin]

Greetings, Kristian Ivarsson via Cygwin!

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

That's how it works. It's just that Cygwin provides /tmp aliasing as a mount
point option for a better usage experience.

See /etc/fstab - the usertemp FS pseudotype.

I.e.
none /tmp usertemp binary,nouser,posix=1 0 0

If yo have a different TMP (than TEMP), check your shell startup for any
redefinitions.


-- 
With best regards,
Andrey Repin
Sunday, September 20, 2020 10:16:54

Sorry for my terrible english...

Sv: TMP/TEMP environment variable and /tmp

[sten.kristian.ivarsson]

Thanx all who helped out with this

The reason to why we thought it worked in mysterious ways was a coincidence of how it worked in cygwin shell (due to /etc/profile etc) and that we didn't realize/investigate that the variable was NULL at this moment and that we fell back to our own default-value ("/tmp")), that is; cygwin-built-applications works as expected regarding TMP/TEMP-environment variables

Keep up the good work,
Kristian


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