X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
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 DOT inglis AT systematicsw DOT ab DOT ca
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
Subject:	Re: TMP/TEMP environment variable and /tmp
To:	cygwin AT cygwin DOT com
References:	<423c729e-4c66-dd5e-73c0-4c636089ea35 AT cornell DOT edu>
	<EA51058C-D017-4CCE-B207-C5EFD8CCC088 AT gmail DOT com>
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Autocrypt:	addr=Brian DOT Inglis AT SystematicSw DOT ab DOT 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:	<EA51058C-D017-4CCE-B207-C5EFD8CCC088@gmail.com>
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 AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	cygwin AT cygwin DOT com
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 08IDGnv3028406

On 2020-09-17 23:56, Kristian Ivarsson via Cygwin wrote:
> 
>>>>>>>>> Does anyone know the rational with this behaviour and what can be
>>>>>>>>> done to get hold of the (real) Windows TMP/TEMP
>>>>>>>>> environment-variable-values (in a
>>>>>>>>> (hopefully) platform independent way) ?
>>>>>>>> so if you are making your custom tree, try to stick on that
>>>>>>>> expectation and have both directories.
>>>>>>> In general, you are free to set TMP to a directory of your choice,
>>>>>>> that's the purpose of that variable, no need to sync it with some root.
>>>>>>> There is a comment in /etc/profile:
>>>>>>>    # TMP and TEMP as defined in the Windows environment
>>>>>>>    # can have unexpected consequences for cygwin apps, but it does not
>>>>>>> explain what consequences that might be; probably some trouble with
>>>>>>> ACL/access permissions for temporary files.
>>>>>> Nowadays that would be $LOCALAPPDATA/Temp, or if you really insist, the
>>>>>> content of /proc/registry/HKEY_CURRENT_USER/Environment/TMP (or TEMP),
>>>>>> after similarly expanding environment variable references found in that.
>>>>>>
>>>>>> The fact that getting Windows' idea of the user's TEMP directory is not
>>>>>> immediately platform independent may well have been part of the rationale
>>>>>> for not even trying that.
>>>>>
>>>>> Well, at least it's up to the user
>>>>>
>>>>> If the user sets its TMP-variable to "C:\Jabba Dabba Dooo" or "/jabba dabba doo", I expect the value of getenv("TMP") should be just that and regardless of OS the value returned is whatever the variable is set to and not magically changed to "/tmp"
>>>> Of course and that's not happening, no worries. The issue was that TMP is set in /etc/profile and not inherited from the Windows environment.
>>> Well, where my Cygwin-compiled-application is running, there’s no Cygwin-installation and thus no /etc/profile so it cannot be set there (if /etc/profile is not a built in resource in every executable), so there must be some text-value inside the compiled executables used in some manner somehow
>>
>> There must be something going on in your environment that you haven't told us yet.  I just tried the following test case:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> int
>> main ()
>> {
>>  printf ("The value of TMP is %s\n", getenv ("TMP"));
>> }
>>
>> In a Cygwin bash shell I get
>>
>>  The value of TMP is /tmp
>>
>> Running the same executable under a Windows Command Prompt, I get
>>
>>  The value of TMP is /c/Users/kbrown/AppData/Local/Temp
>>
>> So Cygwin converts TMP to a Posix path [*], but it doesn't change it to "/tmp".
>>
>> Ken
>>
>> [*] See environ.cc:303 for a list of environment variables that Cygwin converts.
> 
> Hmm, you’re right Ken
> 
> I tried this before taking off for a vacation and the Windows-TMP-variable is extracted
> 
> I now suspect that we maybe do have some logic that falls back to /tmp if the TMP-variable is NULL and perhaps the variable is NULL because we launch the process with CreateProcess and perhaps the environment-variables doesn’t get inherited then ?
> 
> The reason why we use CreateProcess from within a cygwin-application to create another cygwin-application (instead of fork or such) might seem weird, but it has its reasons
> 
> I need to confirm this after the vacation-trip or if someone already know if environment-variables “dissapear” if things such as CreateProcess are used ?

Programmer optional - same applies for CreateProcessA/W/AsUserA/W:

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

"lpEnvironment

A pointer to the environment block for the new process. If this parameter is
NULL, the new process uses the environment of the calling process.

An environment block consists of a null-terminated block of null-terminated
strings. Each string is in the following form:

	name=value\0

Because the equal sign is used as a separator, it must not be used in the name
of an environment variable.

An environment block can contain either Unicode or ANSI characters. If the
environment block pointed to by lpEnvironment contains Unicode characters, be
sure that dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT. If this parameter
is NULL and the environment block of the parent process contains Unicode
characters, you must also ensure that dwCreationFlags includes
CREATE_UNICODE_ENVIRONMENT.

The ANSI version of this function, CreateProcessA fails if the total size of the
environment block for the process exceeds 32,767 characters.

Note that an ANSI environment block is terminated by two zero bytes: one for the
last string, one more to terminate the block. A Unicode environment block is
terminated by four zero bytes: two for the last string, two more to terminate
the block."

Note that when MS say "Unicode" they usually mean UTF16LE, which only some
programs support, depending on the I/O functions they use.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -