Re: TMP/TEMP environment variable and /tmp

[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.
>> 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 ?

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

cygwinports domains

[Yaakov Selkowitz]

My domain registrations cygwinports.com, cygwinports.net, and
cygwinports.org will expire very soon.  If anyone would like to adopt
them for the Cygwin project, please let me know ASAP.  Otherwise, I
will let them lapse.

-- 
Yaakov

Re: TMP/TEMP environment variable and /tmp

[Brian Inglis]

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 
>> #include 
>> 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/d187.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/d189.2'
>>
>> P_tmpdir is defined in 
> 
> 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.]
--
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

[PATCH v2] winsup/doc/faq-what.xml: FAQ 1.2 Windows versions supported

[Brian Inglis]

enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008;
add 8.1, exclude S mode, add Cygwin32 on ARM, specify 64 bit only AMD/Intel
---
 winsup/doc/faq-what.xml | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/winsup/doc/faq-what.xml b/winsup/doc/faq-what.xml
index ea8496ccbc65..77ba1c5fdd9c 100644
--- a/winsup/doc/faq-what.xml
+++ b/winsup/doc/faq-what.xml
@@ -30,12 +30,12 @@ They can be used from one of the provided Unix shells like 
bash, tcsh or zsh.
 What versions of Windows are supported?
 
 
-Cygwin can be expected to run on all modern, released versions of 
Windows.
-State January 2016 this includes Windows Vista, Windows Server 2008 and all
-later versions of Windows up to Windows 10 and Windows Server 2016.
+Cygwin can be expected to run on all modern, released versions of 
Windows,
+from Windows Vista, 7, 8, 8.1, 10, Windows Server 2008 and all
+later versions of Windows, except Windows S mode due to its limitations.
 The 32 bit version of Cygwin also runs in the WOW64 32 bit environment on
-released 64 bit versions of Windows, the 64 bit version of course only on
-64 bit Windows.
+released 64 bit versions of Windows including ARM PCs,
+the 64 bit version of course only on 64 bit AMD/Intel compatible PCs.
 
 Keep in mind that Cygwin can only do as much as the underlying OS
 supports.  Because of this, Cygwin will behave differently, and
-- 
2.28.0

Re: TMP/TEMP environment variable and /tmp

[Ken Brown via 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 
#include 
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/d187.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/d189.2'

P_tmpdir is defined in 


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

RE: Cygwin 3.1.5, 3.1.6 and 3.1.7 builds reporting tty errors with OpenSSH Services in indows Event Logs

[Peter Board via Cygwin]

Hi Takashi,

Attached is the ssh_config and sshd_config.

Peter

Sent from Mail for Windows 10

From: Takashi Yano
Sent: Friday, 18 September 2020 10:10 AM
To: cygwin@cygwin.com
Cc: Peter Board
Subject: Re: Cygwin 3.1.5, 3.1.6 and 3.1.7 builds reporting tty errors with 
OpenSSH Services in indows Event Logs

On Thu, 17 Sep 2020 22:44:52 +
Peter Board wrote:
> F:\cygwin64\bin>cygrunsrv -V -L
> Service : cygsshd
> Display name: CYGWIN cygsshd
> Current State   : Running
> Controls Accepted   : Stop
> Command : /usr/sbin/sshd -D
> stdin path  : /dev/null
> stdout path : /var/log/cygsshd.log
> stderr path : /var/log/cygsshd.log
> Environment : CYGWIN="CYGWIN"
> Process Type: Own Process
> Startup : Manual
> Dependencies: tcpip
> Account : LocalSystem

No suspicious settings other than meaningless
> Environment : CYGWIN="CYGWIN"

Could you please attach /etc/ssh_config and /etc/sshd_config ?

--
Takashi Yano 



sshd_config
Description: sshd_config


ssh_config
Description: ssh_config
--
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

Re: Cygwin 3.1.5, 3.1.6 and 3.1.7 builds reporting tty errors with OpenSSH Services in indows Event Logs

[Takashi Yano via Cygwin]

On Thu, 17 Sep 2020 22:44:52 +
Peter Board wrote:
> F:\cygwin64\bin>cygrunsrv -V -L
> Service : cygsshd
> Display name: CYGWIN cygsshd
> Current State   : Running
> Controls Accepted   : Stop
> Command : /usr/sbin/sshd -D
> stdin path  : /dev/null
> stdout path : /var/log/cygsshd.log
> stderr path : /var/log/cygsshd.log
> Environment : CYGWIN="CYGWIN"
> Process Type: Own Process
> Startup : Manual
> Dependencies: tcpip
> Account : LocalSystem

No suspicious settings other than meaningless
> Environment : CYGWIN="CYGWIN"

Could you please attach /etc/ssh_config and /etc/sshd_config ?

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

Re: TMP/TEMP environment variable and /tmp

[Doug Henderson via Cygwin]

On Thu, 17 Sep 2020 at 15:56, Ken Brown via Cygwin <> wrote:
>

#include 
#include 
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/d187.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/d189.2'

P_tmpdir is defined in 


-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
--
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

Re: [PATCH] winsup/doc/faq-what.xml: FAQ 1.2 Windows versions supported

[Brian Inglis]

On 2020-09-17 16:22, Ken Brown via Cygwin-patches wrote:
> On 9/17/2020 2:29 PM, Brian Inglis wrote:
>> Based on thread 
>> https://cygwin.com/pipermail/cygwin/2020-September/246318.html
>> enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008
>> ---
>>   winsup/doc/faq-what.xml | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/winsup/doc/faq-what.xml b/winsup/doc/faq-what.xml
>> index ea8496ccbc65..09747532c2e8 100644
>> --- a/winsup/doc/faq-what.xml
>> +++ b/winsup/doc/faq-what.xml
>> @@ -30,9 +30,9 @@ They can be used from one of the provided Unix shells like
>> bash, tcsh or zsh.
>>   What versions of Windows are supported?
>>   
>>   -Cygwin can be expected to run on all modern, released versions of
>> Windows.
>> -State January 2016 this includes Windows Vista, Windows Server 2008 and all
>> -later versions of Windows up to Windows 10 and Windows Server 2016.
>> +Cygwin can be expected to run on all modern, released versions of 
>> Windows,
>> +from Windows Vista, 7, 8, 10, Windows Server 2008, and all
>> +later versions of Windows.
>>   The 32 bit version of Cygwin also runs in the WOW64 32 bit environment on
>>   released 64 bit versions of Windows, the 64 bit version of course only on
>>   64 bit Windows.
> 
> Since this is something that changes over time, I don't think you should drop
> the date completely, though I see no reason to retain "January 2016".  What
> would you think of revising your patch so that the text says something like 
> this:
> 
> "Cygwin can be expected to run on all modern, released versions of Windows.  
> As
> of September 2020 this includes Windows Vista, 7, 8, 8.1, and 10, Windows 
> Server
> 2008, and all later versions of Windows Server."

No problem with adding 8.1 explicitly if deemed desirable.
See suggested wording - keeping similar wording the same problem recurs each
month - wanna change it monthly? ;^>
Would not want to limit later versions to just Server, and omitted versions
because now Server versions are like W10 updates e.g. WS version 2004, which is
stupid and confusing, as it looks 16 years old!

Damn you for making me think about this! ;^>
We now probably have to add exclusions for Windows S and also mention ARM under
Cygwin32.

Anyone out there interested in starting a Cygwin Windows ARM64 port (and
toolchain fixes for PE/COFF ARM64/AAarch64 machine type 0xAA64 if needed)?

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

Re: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add tsxldtrk, sev_es flags

[Ken Brown via Cygwin-patches]

On 9/17/2020 2:51 PM, Brian Inglis wrote:

Add linux-next cpuinfo flags for Intel TSX suspend load address tracking
instructions and AMD Secure Encrypted Virtualization with Encrypted State
---
  winsup/cygwin/fhandler_proc.cc | 8 
  1 file changed, 8 insertions(+)

diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc
index 196bafd18993..6f6e8291a0ca 100644
--- a/winsup/cygwin/fhandler_proc.cc
+++ b/winsup/cygwin/fhandler_proc.cc
@@ -1376,6 +1376,7 @@ format_proc_cpuinfo (void *, char *)
  cpuid (, , , , 0x801f);
  
  	  ftcprint (features2,  1, "sev");	/* secure encrypted virt */

+   /*ftcprint (features2,  3, "sev_es"); - print below */
}
/* cpuid 0x8008 ebx */
if (maxe >= 0x8008)
@@ -1400,6 +1401,12 @@ format_proc_cpuinfo (void *, char *)
  /*  ftcprint (features1, 26, "ssb_no"); *//* ssb fixed in hardware */
  }
  
+  /* cpuid 0x801f eax - set above */

+  if (maxe >= 0x801f)
+   {
+ ftcprint (features2,  3, "sev_es"); /* AMD SEV encrypted state */
+   }
+
/* cpuid 0x0007 ebx */
if (maxf >= 0x0007)
{
@@ -1579,6 +1586,7 @@ format_proc_cpuinfo (void *, char *)
ftcprint (features1,  8, "avx512_vp2intersect"); /* vec intcpt d/q 
*/
ftcprint (features1, 10, "md_clear");/* verw clear buf 
*/
ftcprint (features1, 14, "serialize");   /* SERIALIZE 
instruction */
+  ftcprint (features1, 16, "tsxldtrk"); /* TSX Susp Ld 
Addr Track */
ftcprint (features1, 18, "pconfig"); /* platform 
config */
ftcprint (features1, 19, "arch_lbr");/* last branch 
records */
ftcprint (features1, 28, "flush_l1d");   /* flush l1d cache */


Pushed with a trivial change (added a period at the end of the commit message).

Thanks.

Ken

Re: [PATCH] winsup/doc/faq-what.xml: FAQ 1.2 Windows versions supported

[Ken Brown via Cygwin-patches]

On 9/17/2020 2:29 PM, Brian Inglis wrote:

Based on thread https://cygwin.com/pipermail/cygwin/2020-September/246318.html
enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008
---
  winsup/doc/faq-what.xml | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/winsup/doc/faq-what.xml b/winsup/doc/faq-what.xml
index ea8496ccbc65..09747532c2e8 100644
--- a/winsup/doc/faq-what.xml
+++ b/winsup/doc/faq-what.xml
@@ -30,9 +30,9 @@ They can be used from one of the provided Unix shells like 
bash, tcsh or zsh.
  What versions of Windows are supported?
  
  
-Cygwin can be expected to run on all modern, released versions of Windows.

-State January 2016 this includes Windows Vista, Windows Server 2008 and all
-later versions of Windows up to Windows 10 and Windows Server 2016.
+Cygwin can be expected to run on all modern, released versions of 
Windows,
+from Windows Vista, 7, 8, 10, Windows Server 2008, and all
+later versions of Windows.
  The 32 bit version of Cygwin also runs in the WOW64 32 bit environment on
  released 64 bit versions of Windows, the 64 bit version of course only on
  64 bit Windows.


Since this is something that changes over time, I don't think you should drop 
the date completely, though I see no reason to retain "January 2016".  What 
would you think of revising your patch so that the text says something like this:


"Cygwin can be expected to run on all modern, released versions of Windows.  As 
of September 2020 this includes Windows Vista, 7, 8, 8.1, and 10, Windows Server 
2008, and all later versions of Windows Server."


Ken

Re: TMP/TEMP environment variable and /tmp

[Ken Brown via 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 
#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.
--
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

Re: Windows 7, cygwin > 3.1.4 symlink issue

[Ken Brown via Cygwin]

On 9/17/2020 4:27 PM, Roland Roberts wrote:

On 8/24/2020 5:43 PM, Roland Roberts wrote:
I have one machine, a company machine which makes it hard to post details, 
which is running Windows 7. We run cygwin as our development environment for 
Java, but Java is installed as a Windows program. The scripts that do the 
builds are bash scripts that pull down updated code from svn, then run unit 
tests. All of the cygwin bits work fine, but when Java is launched to run the 
unit tests, it runs into problems with reading files that were created as 
symlinks in cygwin. Note that this does *not* happen with cygwin 3.1.4, but 
does with higher versions (up through 3.1.7).


Possibly related, the permissions on installed files is odd if I roll back 
from > 3.1.4 to 3.1.4. The files that were updated with the later version 
can't be deleted. The permissions on, for example, an Emacs upgraded under 
3.1.6 or 3.1.7 show "Unknown User" when I downgrade just cygwin and I can't 
run it. I have to upgrade cygwin, uninstall Emacs, downgrade cygwin then 
reinstall.


Other users in the company have had their machines upgraded/replaced with 
Windows 10 and don't seem to have this issue. Eventually, mine will be 
replaced as well, but in the meantime, later versions of cygwin can't be used.


Okay, I have no idea what form of dyslexia struck me when I wrote all those 
version numbers, but I've edited the above since it wasn't 1.x but 3.1.x


Starting with Cygwin 3.1.5, Cygwin changed its default method of creating
symlinks.  They are now special reparse points known as "WSL symlinks" on 
systems that support reparse points.


If you create such a symlink in Cygwin > 3.1.4 and then roll back to an earlier 
version, Cygwin won't recognize the file type.  (But Windows 10 with WSL will 
recognize it.)


If you're using tools that don't work with the new style of symlink, you can use 
the CYGWIN environment variable to change the way Cygwin creates symlinks.


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

Re: TMP/TEMP environment variable and /tmp

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

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

Re: Windows 7, cygwin > 3.1.4 symlink issue

[Roland Roberts]

On 8/24/2020 5:43 PM, Roland Roberts wrote:
I have one machine, a company machine which makes it hard to post 
details, which is running Windows 7. We run cygwin as our development 
environment for Java, but Java is installed as a Windows program. The 
scripts that do the builds are bash scripts that pull down updated 
code from svn, then run unit tests. All of the cygwin bits work fine, 
but when Java is launched to run the unit tests, it runs into problems 
with reading files that were created as symlinks in cygwin. Note that 
this does *not* happen with cygwin 3.1.4, but does with higher 
versions (up through 3.1.7).


Possibly related, the permissions on installed files is odd if I roll 
back from > 3.1.4 to 3.1.4. The files that were updated with the later 
version can't be deleted. The permissions on, for example, an Emacs 
upgraded under 3.1.6 or 3.1.7 show "Unknown User" when I downgrade 
just cygwin and I can't run it. I have to upgrade cygwin, uninstall 
Emacs, downgrade cygwin then reinstall.


Other users in the company have had their machines upgraded/replaced 
with Windows 10 and don't seem to have this issue. Eventually, mine 
will be replaced as well, but in the meantime, later versions of 
cygwin can't be used.


Okay, I have no idea what form of dyslexia struck me when I wrote all 
those version numbers, but I've edited the above since it wasn't 1.x but 
3.1.x


roland

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

[PATCH] fhandler_proc.cc(format_proc_cpuinfo): add tsxldtrk, sev_es flags

[Brian Inglis]

Add linux-next cpuinfo flags for Intel TSX suspend load address tracking
instructions and AMD Secure Encrypted Virtualization with Encrypted State
---
 winsup/cygwin/fhandler_proc.cc | 8 
 1 file changed, 8 insertions(+)

diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc
index 196bafd18993..6f6e8291a0ca 100644
--- a/winsup/cygwin/fhandler_proc.cc
+++ b/winsup/cygwin/fhandler_proc.cc
@@ -1376,6 +1376,7 @@ format_proc_cpuinfo (void *, char *)
  cpuid (, , , , 0x801f);
 
  ftcprint (features2,  1, "sev");  /* secure encrypted virt */
+   /*ftcprint (features2,  3, "sev_es"); - print below */
}
   /* cpuid 0x8008 ebx */
   if (maxe >= 0x8008)
@@ -1400,6 +1401,12 @@ format_proc_cpuinfo (void *, char *)
 /*   ftcprint (features1, 26, "ssb_no");   *//* ssb fixed in hardware */
 }
 
+  /* cpuid 0x801f eax - set above */
+  if (maxe >= 0x801f)
+   {
+ ftcprint (features2,  3, "sev_es");   /* AMD SEV encrypted state */
+   }
+
   /* cpuid 0x0007 ebx */
   if (maxf >= 0x0007)
{
@@ -1579,6 +1586,7 @@ format_proc_cpuinfo (void *, char *)
   ftcprint (features1,  8, "avx512_vp2intersect"); /* vec intcpt d/q */
   ftcprint (features1, 10, "md_clear");/* verw clear buf */
   ftcprint (features1, 14, "serialize");   /* SERIALIZE 
instruction */
+  ftcprint (features1, 16, "tsxldtrk");   /* TSX Susp 
Ld Addr Track */
   ftcprint (features1, 18, "pconfig");/* platform config */
   ftcprint (features1, 19, "arch_lbr");   /* last 
branch records */
   ftcprint (features1, 28, "flush_l1d");  /* flush l1d cache */
-- 
2.28.0

[PATCH] winsup/doc/faq-what.xml: FAQ 1.2 Windows versions supported

[Brian Inglis]

Based on thread https://cygwin.com/pipermail/cygwin/2020-September/246318.html
enumerate Vista, 7, 8, 10 progression to be clear, and earliest server 2008
---
 winsup/doc/faq-what.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/winsup/doc/faq-what.xml b/winsup/doc/faq-what.xml
index ea8496ccbc65..09747532c2e8 100644
--- a/winsup/doc/faq-what.xml
+++ b/winsup/doc/faq-what.xml
@@ -30,9 +30,9 @@ They can be used from one of the provided Unix shells like 
bash, tcsh or zsh.
 What versions of Windows are supported?
 
 
-Cygwin can be expected to run on all modern, released versions of 
Windows.
-State January 2016 this includes Windows Vista, Windows Server 2008 and all
-later versions of Windows up to Windows 10 and Windows Server 2016.
+Cygwin can be expected to run on all modern, released versions of 
Windows,
+from Windows Vista, 7, 8, 10, Windows Server 2008, and all
+later versions of Windows.
 The 32 bit version of Cygwin also runs in the WOW64 32 bit environment on
 released 64 bit versions of Windows, the 64 bit version of course only on
 64 bit Windows.
-- 
2.28.0

Updated: mintty 3.4.0

[Thomas Wolff]

I have uploaded mintty 3.4.0 with the following changes:

Highlights
  * Optional tabbar.
  * Supporting new xterm mouse mode with pixel reporting.

Window handling / Tabs
  * Optional tabbar for interactive virtual tabs session switching (#944).
  * Fixed maximised/fullscreen synchronisation among sessions/tabs.
  * Fixed state inconsistencies after minimizing synchronized windows 
(#699, ~#944).


Window handling
  * Fixed offset of saved image.
  * Fixed themes list and interactive theme switching feedback 
(mintty/wsltty#251).

  * Support system hotkey for activation in "Quake mode" (#1029).

Mouse handling
  * If ZoomMouse=false, Ctrl+mouse-wheel scrolls by 1 line per notch 
(#1032).

  * Configurable number of scroll lines per mouse wheel notch (#1032).
  * Support mousewheel reporting (e.g. for shell history scrolling) in 
normal screen mode (~#1032).
  * Nudge complete delivery of application scrollbar sequences by delay 
(#1033).


Terminal features
  * Mouse mode 1016 with pixel coordinates (xterm 360).
  * XTPUSHSGR foreground/background changed to 30/31 (xterm 357).
  * Align OSC response terminator (ST or BEL) with request terminator 
(#1028, xterm).
  * Fixed invalid IME cursor colour after OSC 112 "Reset cursor colour" 
(#942).


Configuration
  * New option TabBar and command-line option --tabbar (#944).
  * New user-definable functions clear-title, refresh.
  * New option LinesPerMouseWheelNotch (#1032).
  * Option KeyFunctions: flexible specification of modifiers (in any 
order).


The homepage is at http://mintty.github.io/
It also links to the issue tracker.

--
Thomas

[ANNOUNCEMENT] Updated: mintty 3.4.0

[Thomas Wolff]

I have uploaded mintty 3.4.0 with the following changes:

Highlights
  * Optional tabbar.
  * Supporting new xterm mouse mode with pixel reporting.

Window handling / Tabs
  * Optional tabbar for interactive virtual tabs session switching (#944).
  * Fixed maximised/fullscreen synchronisation among sessions/tabs.
  * Fixed state inconsistencies after minimizing synchronized windows 
(#699, ~#944).


Window handling
  * Fixed offset of saved image.
  * Fixed themes list and interactive theme switching feedback 
(mintty/wsltty#251).

  * Support system hotkey for activation in "Quake mode" (#1029).

Mouse handling
  * If ZoomMouse=false, Ctrl+mouse-wheel scrolls by 1 line per notch 
(#1032).

  * Configurable number of scroll lines per mouse wheel notch (#1032).
  * Support mousewheel reporting (e.g. for shell history scrolling) in 
normal screen mode (~#1032).
  * Nudge complete delivery of application scrollbar sequences by delay 
(#1033).


Terminal features
  * Mouse mode 1016 with pixel coordinates (xterm 360).
  * XTPUSHSGR foreground/background changed to 30/31 (xterm 357).
  * Align OSC response terminator (ST or BEL) with request terminator 
(#1028, xterm).
  * Fixed invalid IME cursor colour after OSC 112 "Reset cursor colour" 
(#942).


Configuration
  * New option TabBar and command-line option --tabbar (#944).
  * New user-definable functions clear-title, refresh.
  * New option LinesPerMouseWheelNotch (#1032).
  * Option KeyFunctions: flexible specification of modifiers (in any 
order).


The homepage is at http://mintty.github.io/
It also links to the issue tracker.

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

Nationwide Construction Estimates!!

[projects--- via Cygwin]

Hi,

Hope you are doing well,

We are providing all types of construction estimates and take-offs to
building professionals and owner-builders. Our estimators have experience
providing estimates on residential, commercial, and civil construction
projects.

Reply to this email for any samples or queries, or send us the
Drawings/plans in PDF or any link. Looking forward to hearing from you soon.

 

Kind Regards,

Tommy

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

Re: Cygwin 3.1.5, 3.1.6 and 3.1.7 builds reporting tty errors with OpenSSH Services in indows Event Logs

[Takashi Yano via Cygwin]

On Tue, 15 Sep 2020 23:46:30 +
Peter Board via Cygwin wrote:
> Hi Stephen,
> 
> Thanks for responding. I have a standard Cygwin install on my Development 
> server (32bit and 64bit setups) that I extract the updates from for our 
> custom package and I tested for the fault after I saw it was occurring in our 
> custom Cygwin install using the standard Cygwin setup. The same errors are 
> being logged in the standard Cygwin install. I ran the Cygwin sshd 
> installation script in the standard 64bit Cygwin install, to create the 
> Cygwin OpenSSH service, authorised my user account to login and found that 
> the Windows Event logs also logged the same errors as our normal package 
> location.
> 
> I keep the standard installs on “F:\Cygwin” (32bit Cygwin) and “F:\Cygwin64” 
> (64bit Cygwin).
> 
> Our Custom Cygwin \ OpenSSH package lives on “C:\Program Files(x86)\OpenSSH”, 
> which is where we have kept it for 15+ odd years.
> 
> After setting up the Cygwin (64bit version) just using a out of the box 
> Cygwin installer on F:\Cygwin64, I setup OpenSSH using the built in 
> /bin/ssh-host-config script and then authorised my user to login to the 
> “cygsshd” service. The standard SSH service with no modifications from me, 
> produces these errors in the Windows Event Logs.
> 
> It accepted the password and logged the user in fine to bash shell. (I’ve 
> removed the hostname and username from the example below)
> 
> -- Event Log Entries 
> 
> Log Name:  Application
> Source:sshd
> Date:  14/09/2020 4:30:26 PM
> Event ID:  0
> Task Category: None
> Level: Information
> Keywords:  Classic
> User:  SYSTEM
> Computer:  hostname
> Description:
> The description for Event ID 0 from source sshd cannot be found. Either the 
> component that raises this event is not installed on your local computer or 
> the installation is corrupted. You can install or repair the component on the 
> local computer.
> 
> If the event originated on another computer, the display information had to 
> be saved with the event.
> 
> The following information was included with the event:
> 
> sshd: PID 1620: Accepted password for USERNAME from X.X.X.X port 56545 ssh2
> 
> Event Xml:
> http://schemas.microsoft.com/win/2004/08/events/event;>
>   
> 
> 0
> 4
> 0
> 0x80
> 
> 2427841
> Application
> hostname
> 
>   
>   
> sshd: PID 1620: Accepted password for USERNAME from X.X.X.X port 
> 56545 ssh2
>   
> 
> 
> -- Event Log Entries 
> 
> Log Name:  Application
> Source:sshd
> Date:  14/09/2020 4:30:27 PM
> Event ID:  0
> Task Category: None
> Level: Error
> Keywords:  Classic
> User:  SYSTEM
> Computer:  hostname
> Description:
> The description for Event ID 0 from source sshd cannot be found. Either the 
> component that raises this event is not installed on your local computer or 
> the installation is corrupted. You can install or repair the component on the 
> local computer.
> 
> If the event originated on another computer, the display information had to 
> be saved with the event.
> 
> The following information was included with the event:
> 
> sshd: PID 1622: error: Failed to disconnect from controlling tty.
> 
> Event Xml:
> http://schemas.microsoft.com/win/2004/08/events/event;>
>   
> 
> 0
> 2
> 0
> 0x80
> 
> 2427842
> Application
> hostname
> 
>   
>   
> sshd: PID 1622: error: Failed to disconnect from controlling 
> tty.
>   
> 
> -- Event Log Entries 
> 
> Log Name:  Application
> Source:sshd
> Date:  14/09/2020 4:30:27 PM
> Event ID:  0
> Task Category: None
> Level: Error
> Keywords:  Classic
> User:  SYSTEM
> Computer:  hostname
> Description:
> The description for Event ID 0 from source sshd cannot be found. Either the 
> component that raises this event is not installed on your local computer or 
> the installation is corrupted. You can install or repair the component on the 
> local computer.
> 
> If the event originated on another computer, the display information had to 
> be saved with the event.
> 
> The following information was included with the event:
> 
> sshd: PID 1622: error: ioctl(TIOCSCTTY): Operation not permitted
> 
> Event Xml:
> http://schemas.microsoft.com/win/2004/08/events/event;>
>   
> 
> 0
> 2
> 0
> 0x80
> 
> 2427843
> Application
>  hostname 
> 
>   
>   
> sshd: PID 1622: error: ioctl(TIOCSCTTY): Operation not 
> permitted
>   
> 
> 
> -- End of Entries --

What does the following command say?

cygrunsrv -V -L

-- 
Takashi Yano 
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: 

Re: Cygwin 3.1.5, 3.1.6 and 3.1.7 builds reporting tty errors with OpenSSH Services in indows Event Logs

[Stephen Carrier]

Please don't top-post in this list.  I'll move your reply down.

>From: [2]Stephen Carrier
>Sent: Wednesday, 16 September 2020 2:22 AM
>To: [3]Peter Board
>Cc: [4]cygwin@cygwin.com
>Subject: Re: Cygwin 3.1.5, 3.1.6 and 3.1.7 builds reporting tty errors
>with OpenSSH Services in indows Event Logs
> 
> 
>On Mon, Sep 14, 2020 at 08:18:53AM +, Peter Board via Cygwin wrote:
>> Hi,
>>
>> I am trying to update our Cygwin libraries at work, which we use on
>many servers to provide OpenSSH services.
>> I have been making update packages for many years from a Cygwin
>install on a development server, and went to update our systems to the
>latest OpenSSH 8.3p1 build.
>>
>> However after making the update package, I found that the Windows
>Event Log (or if Syslogd is setup – which we do have in our general
>Cygwin deployment /var/log/messages) gets two errors when using any
>version of the Cygwin Libraries after the 3.1.4 build.
>>
>>
>> Sep 14 12:06:48 hostname sshd: PID 2093: error: Failed to disconnect
>from controlling tty.
>>
>> Sep 14 12:06:48 hostname sshd: PID 2093: error: ioctl(TIOCSCTTY):
>Operation not permitted
>Can this be reproduced in a standard cygwin install?  It seems as if
>your have a customized environment where you compile your own packages,
>and updated the cygwin libs perhaps w/o updating openssh at the same
>time.
>Stephen
> 
> References
> 
>1. https://go.microsoft.com/fwlink/?LinkId=550986
>2. mailto:carr...@berkeley.edu
>3. mailto:p_bo...@hotmail.com
>4. mailto:cygwin@cygwin.com

On Tue, Sep 15, 2020 at 11:46:30PM +, Peter Board wrote:
>Hi Stephen,
> 
> 
>Thanks for responding. I have a standard Cygwin install on my
>Development server (32bit and 64bit setups) that I extract the updates
>from for our custom package and I tested for the fault after I saw it
>was occurring in our custom Cygwin install using the standard Cygwin
>setup. The same errors are being logged in the standard Cygwin install.
>I ran the Cygwin sshd installation script in the standard 64bit Cygwin
>install, to create the Cygwin OpenSSH service, authorised my user
>account to login and found that the Windows Event logs also logged the
>same errors as our normal package location.
> 
> 
>I keep the standard installs on “F:\Cygwin” (32bit Cygwin) and
>“F:\Cygwin64” (64bit Cygwin).
> 
> 
>Our Custom Cygwin \ OpenSSH package lives on “C:\Program
>Files(x86)\OpenSSH”, which is where we have kept it for 15+ odd years.
> 
> 
>After setting up the Cygwin (64bit version) just using a out of the box
>Cygwin installer on F:\Cygwin64, I setup OpenSSH using the built in
>/bin/ssh-host-config script and then authorised my user to login to the
>“cygsshd” service. The standard SSH service with no modifications from
>me, produces these errors in the Windows Event Logs.
> 
> 
>It accepted the password and logged the user in fine to bash shell.
>(I’ve removed the hostname and username from the example below)
> 
> 
>-- Event Log Entries 
> 
> 
>Log Name:  Application
> 
>Source:sshd
> 
>Date:  14/09/2020 4:30:26 PM
> 
>Event ID:  0
> 
>Task Category: None
> 
>Level: Information
> 
>Keywords:  Classic
> 
>User:  SYSTEM
> 
>Computer:  hostname
> 
>Description:
> 
>The description for Event ID 0 from source sshd cannot be found. Either
>the component that raises this event is not installed on your local
>computer or the installation is corrupted. You can install or repair
>the component on the local computer.
> 
> 
>If the event originated on another computer, the display information
>had to be saved with the event.
> 
> 
>The following information was included with the event:
> 
> 
>sshd: PID 1620: Accepted password for USERNAME from X.X.X.X port 56545
>ssh2
> 
> 
>Event Xml:
> 
>http://schemas.microsoft.com/win/2004/08/events/event;>
> 
>  
> 
>
> 
>0
> 
>4
> 
>0
> 
>0x80
> 
>
> 
>2427841
> 
>Application
> 
>hostname
> 
>
> 
>  
> 
>  
> 
>sshd: PID 1620: Accepted password for USERNAME from X.X.X.X
>port 56545 ssh2
> 
>  
> 
>
> 
> 
>-- Event Log Entries 
> 
> 
>Log Name:  Application
> 
>Source:sshd
> 
>Date:  14/09/2020 4:30:27 PM
> 
>Event ID:  0
> 
>Task Category: None
> 
>Level: Error
> 
>Keywords:  Classic
> 
>User:  SYSTEM
> 
>Computer:  hostname
> 
>Description:
> 
>The description for Event ID 0 from source sshd cannot be found. Either
>the component that raises this event is not installed on your local
>

Re: TMP/TEMP environment variable and /tmp

[Ken Brown via 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
 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
--
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

Re: Windows 2019 support?

[Bill Stewart]

On Thu, Sep 17, 2020 at 7:58 AM Chris Bovitz wrote:

Cygwin can be expected to run on all modern, released versions of Windows.
> State [sic] January 2016 this includes Windows Vista, Windows Server 2008
> and all later versions of Windows up to Windows 10 and Windows Server 2016.
>
> To me, this implies that Windows Server 2019 is supported, but is that
> true?  If so, could the FAQ be updated to show that?  Thanks.
>

Windows Server 2019 is just the server version of Windows 10 1809. In my
testing it works without any issues.

My recommendation is for the FAQ to state:

"Cygwin can be expected to run on all modern, released versions of Windows.
Since January 2016 this includes Windows Vista, Windows Server 2008, and
all later versions."

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

Re: Sv: TMP/TEMP environment variable and /tmp

[Thomas Wolff]

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.

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

Windows 2019 support?

[Chris Bovitz via Cygwin]

In the FAQ, item 1.2 (What version of Windows are supported?), it says this:

Cygwin can be expected to run on all modern, released versions of Windows. 
State [sic] January 2016 this includes Windows Vista, Windows Server 2008 and 
all later versions of Windows up to Windows 10 and Windows Server 2016.

To me, this implies that Windows Server 2019 is supported, but is that true?  
If so, could the FAQ be updated to show that?  Thanks.


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

Sv: TMP/TEMP environment variable and /tmp

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


Best regards,
Kristian

[snip]


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