* TMP/TEMP environment variable and /tmp @ 2020-09-16 8:51 sten.kristian.ivarsson 2020-09-16 11:04 ` marco atzeri 0 siblings, 1 reply; 16+ messages in thread From: sten.kristian.ivarsson @ 2020-09-16 8:51 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-16 8:51 TMP/TEMP environment variable and /tmp sten.kristian.ivarsson @ 2020-09-16 11:04 ` marco atzeri 2020-09-16 11:12 ` Thomas Wolff 0 siblings, 1 reply; 16+ messages in thread From: marco atzeri @ 2020-09-16 11:04 UTC (permalink / raw) To: sten.kristian.ivarsson; +Cc: The Cygwin Mailing List 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-16 11:04 ` marco atzeri @ 2020-09-16 11:12 ` Thomas Wolff 2020-09-16 19:27 ` Hans-Bernhard Bröker 2020-09-17 16:13 ` Ken Brown 0 siblings, 2 replies; 16+ messages in thread From: Thomas Wolff @ 2020-09-16 11:12 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-16 11:12 ` Thomas Wolff @ 2020-09-16 19:27 ` Hans-Bernhard Bröker 2020-09-17 12:12 ` Sv: " sten.kristian.ivarsson 2020-09-17 16:13 ` Ken Brown 1 sibling, 1 reply; 16+ messages in thread From: Hans-Bernhard Bröker @ 2020-09-16 19:27 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Sv: TMP/TEMP environment variable and /tmp 2020-09-16 19:27 ` Hans-Bernhard Bröker @ 2020-09-17 12:12 ` sten.kristian.ivarsson 2020-09-17 15:23 ` Thomas Wolff 2020-09-20 7:20 ` Andrey Repin 0 siblings, 2 replies; 16+ messages in thread From: sten.kristian.ivarsson @ 2020-09-17 12:12 UTC (permalink / raw) To: 'Hans-Bernhard Bröker', 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" Best regards, Kristian [snip] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Sv: TMP/TEMP environment variable and /tmp 2020-09-17 12:12 ` Sv: " sten.kristian.ivarsson @ 2020-09-17 15:23 ` Thomas Wolff 2020-09-17 21:07 ` Kristian Ivarsson 2020-09-20 7:20 ` Andrey Repin 1 sibling, 1 reply; 16+ messages in thread From: Thomas Wolff @ 2020-09-17 15:23 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-17 15:23 ` Thomas Wolff @ 2020-09-17 21:07 ` Kristian Ivarsson 2020-09-17 21:55 ` Ken Brown 0 siblings, 1 reply; 16+ messages in thread From: Kristian Ivarsson @ 2020-09-17 21:07 UTC (permalink / raw) To: Thomas Wolff; +Cc: 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. 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-17 21:07 ` Kristian Ivarsson @ 2020-09-17 21:55 ` Ken Brown 2020-09-17 23:58 ` Doug Henderson 2020-09-18 5:56 ` Kristian Ivarsson 0 siblings, 2 replies; 16+ messages in thread From: Ken Brown @ 2020-09-17 21:55 UTC (permalink / raw) To: Kristian Ivarsson; +Cc: cygwin 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-17 21:55 ` Ken Brown @ 2020-09-17 23:58 ` Doug Henderson 2020-09-18 2:17 ` Ken Brown 2020-09-18 5:56 ` Kristian Ivarsson 1 sibling, 1 reply; 16+ messages in thread From: Doug Henderson @ 2020-09-17 23:58 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-17 23:58 ` Doug Henderson @ 2020-09-18 2:17 ` Ken Brown 2020-09-18 3:56 ` Brian Inglis 0 siblings, 1 reply; 16+ messages in thread From: Ken Brown @ 2020-09-18 2:17 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-18 2:17 ` Ken Brown @ 2020-09-18 3:56 ` Brian Inglis 0 siblings, 0 replies; 16+ messages in thread From: Brian Inglis @ 2020-09-18 3:56 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-17 21:55 ` Ken Brown 2020-09-17 23:58 ` Doug Henderson @ 2020-09-18 5:56 ` Kristian Ivarsson 2020-09-18 13:15 ` Brian Inglis 1 sibling, 1 reply; 16+ messages in thread From: Kristian Ivarsson @ 2020-09-18 5:56 UTC (permalink / raw) To: Ken Brown; +Cc: 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. >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-18 5:56 ` Kristian Ivarsson @ 2020-09-18 13:15 ` Brian Inglis 2020-09-21 7:57 ` Sv: " sten.kristian.ivarsson 0 siblings, 1 reply; 16+ messages in thread From: Brian Inglis @ 2020-09-18 13:15 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Sv: TMP/TEMP environment variable and /tmp 2020-09-18 13:15 ` Brian Inglis @ 2020-09-21 7:57 ` sten.kristian.ivarsson 0 siblings, 0 replies; 16+ messages in thread From: sten.kristian.ivarsson @ 2020-09-21 7:57 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Sv: TMP/TEMP environment variable and /tmp 2020-09-17 12:12 ` Sv: " sten.kristian.ivarsson 2020-09-17 15:23 ` Thomas Wolff @ 2020-09-20 7:20 ` Andrey Repin 1 sibling, 0 replies; 16+ messages in thread From: Andrey Repin @ 2020-09-20 7:20 UTC (permalink / raw) To: Kristian Ivarsson via Cygwin, cygwin 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... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TMP/TEMP environment variable and /tmp 2020-09-16 11:12 ` Thomas Wolff 2020-09-16 19:27 ` Hans-Bernhard Bröker @ 2020-09-17 16:13 ` Ken Brown 1 sibling, 0 replies; 16+ messages in thread From: Ken Brown @ 2020-09-17 16:13 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-09-21 7:57 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-16 8:51 TMP/TEMP environment variable and /tmp sten.kristian.ivarsson 2020-09-16 11:04 ` marco atzeri 2020-09-16 11:12 ` Thomas Wolff 2020-09-16 19:27 ` Hans-Bernhard Bröker 2020-09-17 12:12 ` Sv: " sten.kristian.ivarsson 2020-09-17 15:23 ` Thomas Wolff 2020-09-17 21:07 ` Kristian Ivarsson 2020-09-17 21:55 ` Ken Brown 2020-09-17 23:58 ` Doug Henderson 2020-09-18 2:17 ` Ken Brown 2020-09-18 3:56 ` Brian Inglis 2020-09-18 5:56 ` Kristian Ivarsson 2020-09-18 13:15 ` Brian Inglis 2020-09-21 7:57 ` Sv: " sten.kristian.ivarsson 2020-09-20 7:20 ` Andrey Repin 2020-09-17 16:13 ` Ken Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).