From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) by sourceware.org (Postfix) with ESMTPS id 0F9593857C46 for ; Fri, 18 Sep 2020 13:15:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0F9593857C46 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id JGEvkPPvnHxtDJGEwkeUxi; Fri, 18 Sep 2020 07:15:51 -0600 X-Authority-Analysis: v=2.4 cv=Ce22WJnl c=1 sm=1 tr=0 ts=5f64b307 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=yMhMjlubAAAA:8 a=D-hjUeOzi2gWLipTs3oA:9 a=PkUIETZosMZSfGuj:21 a=QEXdDO2ut3YA:10 Reply-To: cygwin@cygwin.com Subject: Re: TMP/TEMP environment variable and /tmp To: cygwin@cygwin.com References: <423c729e-4c66-dd5e-73c0-4c636089ea35@cornell.edu> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: <26bcd00c-683e-1c0c-4543-a37db10f9a3e@SystematicSw.ab.ca> Date: Fri, 18 Sep 2020 07:15:49 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfNS67LnGqFUM8WqsFKvX1h4jULcvJKqyIeHUGddBBKLA032SykSHQqnufOmQhRttk6DJpmy5YE2fFbizP4P+6jKz6hZm3+q1mU/vaimiMTACzoTZrYwY 3fu/xJvkX290R9kViFhsDyM1r6t0G6ZxMmxfQVOqYen+KmYdUA7KzYF6Irp6ofzkcOekdWvK503R2nx3l3+maya3nsv7qtyfizA= X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 13:16:18 -0000 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 >> #include >> 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.]