Sv: TMP/TEMP environment variable and /tmp

[sten.kristian.ivarsson@gmail.com]

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