X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA83D3861867
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1600675033;
	bh=db32F3/KouEiQJ7/z59cgrf250MyR8kB7s9avc+8MVE=;
	h=To:References:In-Reply-To:Subject:Date:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=Ngo7xdC+dQMm+WCSpDwl7TEPJX0cU2r8p3r2xtXPRdGTb125TbOJSYWToVeiOiOj/
	 RXuvpWCvC/+QNK1lbfkL5+7Fl4AlCALELYu95yLNq0Q/QHUGJcDjtzKhDDv5svDa/U
	 wQgmJFdTGdzz/MKCNKMkOkuE9yC+rA+6dlV8fYI8=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D2B9A3857C5B
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:references:in-reply-to:subject:date
 :message-id:mime-version:content-transfer-encoding:thread-index
 :content-language;
 bh=AZm0chQC72b475Rkif3ICx7fEcV3c+fiReGCRY4DGCA=;
 b=i7gyqQFS/chp655NLS9RpanyLnee1tSmbj7AU2XVG4GkWEF6pqdsmZl8XB1ATJHodN
 rnDS8nb+/V3CwxOCOspn+oVRAkCs2WmkTqf5U8aQabkNB6qUc3HG6cwRVRN1BVszkodT
 llTvMrS7gFaPovgUWtwjFbqAbNWa4n62/W/1aihBF2KqenjLxGRGlFDTm6qVJLxk8Ayj
 G3W73kX5uYyPA+0m5On6+AwrljK+7TddSpUh/xA5SW7EKlIJJW6VIb4NyaqDyJuAiygI
 6JwbeUrneUizKcs5ebi3vqzV7+2LjX/H1UNS3ZmE84j2V2WiLz10RLvOYrElMTGgBeXC
 mPyw==
X-Gm-Message-State: AOAM531B5QpiMqxkqv1ihK3RBMfuOxB+1/RGSaZ9upaX6Nx2ksMfaP59
 klRmyhOj/vvx/8LPAxCuxFqmhNC3itg=
X-Google-Smtp-Source: ABdhPJzjsSyYG3CpiBIOXIy0Ry+pAzdUUBO2/PNJfXsq/QhHtKkF4iIL8FqqAc4iUF7/FoYHygWPvw==
X-Received: by 2002:a2e:6c03:: with SMTP id h3mr14387948ljc.212.1600675027307; 
 Mon, 21 Sep 2020 00:57:07 -0700 (PDT)
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>
 <26bcd00c-683e-1c0c-4543-a37db10f9a3e AT SystematicSw DOT ab DOT ca>
In-Reply-To: <26bcd00c-683e-1c0c-4543-a37db10f9a3e@SystematicSw.ab.ca>
Subject: Sv: TMP/TEMP environment variable and /tmp
Date: Mon, 21 Sep 2020 09:57:06 +0200
Message-ID: <003201d68fec$ccf15470$66d3fd50$@gmail.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHkSIEitcCt6KiIlwKkTxtCDttpVQG4MuEGAZ4QYr+pPJUPAA==
Content-Language: en-gb
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, 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-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>
From: Kristian Ivarsson via Cygwin <cygwin AT cygwin DOT com>
Reply-To: sten DOT kristian DOT ivarsson AT gmail DOT com
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 08L7vesP015590

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

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