Re: 'tac' trying to use "/tmp"; Error: not found
On 2023-04-02 21:22, marco atzeri wrote:
On Sun, Apr 2, 2023 at 9:43 PM Prof. Luis G. Uribe C. wrote:
*| 'tac' utility dies with a not found "/tmp" error. |*
It is preferable to copy the exact command(s) and output into your problem
report. Presumably the input is a pipe or non-seekable device which needs
buffered in a temp file.
I didn't see this problem in older 'tac' versions...
I created "/tmp" under my root directory:
*"c:\tmp"* (Windows 10), *to no avail*.
I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*:
*"../tmp"*, at the same level as other usual folders like:
*bin*, *dev*, *etc*, *lib*, *sbin*...,
and now: *'**tac' works fine**!*
The /tmp directory needs to be created in the Cygwin POSIX root directory "/".
[I am surprised GNU tac does not yet use mmap where available, as an alternative
to seek, as mmap has been around for decades, since 4.4BSD, SysVr4, and Solaris
2.0 days, and should be faster on huge files.]
The expectation for the existence of /tmp directory is well founded
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I assume by accident your installation pruned the directory.
I will not be surprised if other programs also complain, not only tac
You can point to another dir under a shell (or export the env var) using e.g.
$ export TMPDIR=${TMP:-${TEMP:-/tmp}}
or
$ TMPDIR=. tac ...
If you have Cygwin bash and coreutils installed, under bash or a similar shell
with brace expansion you can restore the install directories with:
$ /bin/mkdir -pv -m 0755 /{bin,dev,etc,lib} \
/usr/{bin,lib,local/{bin,etc,lib},src}
$ /bin/mkdir -pv -m 01777 /dev/{mqueue,shm} /etc/fstab.d \
/{home,{,usr/}tmp} /var/{log,run,tmp}
$ /bin/mkdir -pv -m 0666 /var/run/utmp
see:
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=install.cc#l156
If the directories do not have the correct permissions, use chmod to fix them.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: 'tac' trying to use "/tmp"; Error: not found
On Sun, Apr 2, 2023 at 9:43 PM Prof. Luis G. Uribe C. via Cygwin wrote: > > *Bogotá, Sunday April 2nd, 2023* > > *REF: 'tac' trying to use "/tmp"; Error: not found* > *___* > *| 'tac' utility dies with a not found "/tmp" error. |* > *¯¯¯* > I didn't see this problem in older 'tac' versions... > > I created "/tmp" under my root directory: > *"c:\tmp"* (Windows 10), *to no avail*. > > I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*: > *"../tmp"*, at the same level as other usual folders like: > *bin*, *dev*, *etc*, *lib*, *sbin*..., > and now: *'**tac' works fine**!* The expectation for the existence of /tmp directory is well founded https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard I assume by accident your installation pruned the directory. I will not be surprised if other programs also complain, not only tac > Best regards, > > *Eng. Luis G. Uribe C.* > Regards Marco -- 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
'tac' trying to use "/tmp"; Error: not found
*Bogotá, Sunday April 2nd, 2023* *REF: 'tac' trying to use "/tmp"; Error: not found* *___* *| 'tac' utility dies with a not found "/tmp" error. |* *¯¯¯* I didn't see this problem in older 'tac' versions... I created "/tmp" under my root directory: *"c:\tmp"* (Windows 10), *to no avail*. I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*: *"../tmp"*, at the same level as other usual folders like: *bin*, *dev*, *etc*, *lib*, *sbin*..., and now: *'**tac' works fine**!* I think that in *line 70 of "tac.c"*: *ID: tac (GNU coreutils) 9.0Packaged by Cygwin (9.0-1)Copyright (C) 2021 Free Software Foundation, Inc.* ...if it is defined as: *#define DEFAULT_TMPDIR "**..**/tmp"* *instead of* the *actual*: *#define DEFAULT_TMPDIR "/tmp"* it could work fine! Best regards, *Eng. Luis G. Uribe C.* -- 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 and TMPDIR mapping
On Jan 27 09:08, john daintree via Cygwin wrote:
> Hi Audrey.
>
> Here's an example of what's going on:
>
> >>: export TMPDIR=/cygdrive/c/tmp/jd
> >>: export TMPDIR2=/cygdrive/c/tmp/jd2
> >>: cmd.exe
> Microsoft Windows [Version 10.0.22621.1105]
> (c) Microsoft Corporation. All rights reserved.
>
> C:\>echo %TMPDIR%
> C:\tmp\jd
>
> C:\>echo %TMPDIR2%
> /cygdrive/c/tmp/jd2
>
> So, if I set TMPDIR and TMPDIR2 in bash, and then call cmd.exe then TMPDIR
> is changed to c:\tmp\jd but TMPDIR2 is left as /cygdrive/c/tmp/jd2
>
> I was hoping that there's something I can do to get the following in
> cmd.exe:
>
> C:\>echo %TMPDIR2%
> C:\tmp\jd2 # TMPDIR2 "mapped"
> to c:\ in the same way that TMPDIR is
>
> I hope that's a clearer example.
>
> Note that the actual use case is calling other Win32 programs, and the
> environment variable name is different, but the above example is an attempt
> to simplify the repro.
> $PATH is mapped in a similar way. So I assume that there is a list of names
> which are mapped. I'd like to be able to add my own names to that list.
Easy: Don't call the affected Win32 executable directly. Call it
through a child process.
Two scenarios:
- Starting the nativ executable from a shell or a Makefile:
Create a wrapper script which calls
TMPDIR2="$(cygpath -wa ${TMPDIR2})
before calling your native app.
- Starting the nativ executable from your own process:
After fork(), call
const char *tmpdir2_old;
char *tmpdir2_new;
tmpdir2_old = getenv ("TMPDIR2");
tmpdir2_new = (char *) cygwin_create_path (CCP_POSIX_TO_WIN_A,
tmpdir2_old);
setenv ("TMPDIR2", tmpdir2_new, 1);
free (tmpdir2_new);
Then call execve or friends. Alternatively you can construct the
new environment like the above for any exec call taking an
environment as argument, i.e, execve, execle, execvpe.
Corinna
--
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 and TMPDIR mapping
Hi Audrey. Here's an example of what's going on: >>: export TMPDIR=/cygdrive/c/tmp/jd >>: export TMPDIR2=/cygdrive/c/tmp/jd2 >>: cmd.exe Microsoft Windows [Version 10.0.22621.1105] (c) Microsoft Corporation. All rights reserved. C:\>echo %TMPDIR% C:\tmp\jd C:\>echo %TMPDIR2% /cygdrive/c/tmp/jd2 So, if I set TMPDIR and TMPDIR2 in bash, and then call cmd.exe then TMPDIR is changed to c:\tmp\jd but TMPDIR2 is left as /cygdrive/c/tmp/jd2 I was hoping that there's something I can do to get the following in cmd.exe: C:\>echo %TMPDIR2% C:\tmp\jd2 # TMPDIR2 "mapped" to c:\ in the same way that TMPDIR is I hope that's a clearer example. Note that the actual use case is calling other Win32 programs, and the environment variable name is different, but the above example is an attempt to simplify the repro. $PATH is mapped in a similar way. So I assume that there is a list of names which are mapped. I'd like to be able to add my own names to that list. Thanks. John. -Original Message- From: Andrey Repin Sent: 27 January 2023 07:45 To: john daintree ; cygwin@cygwin.com Subject: Re: TMP and TMPDIR mapping Greetings, john daintree! > My understanding is that Cygwin maps $TMP and $TMPDIR (and probably others) > to a Windows form (/cygdrive/c/tmp -> C:\tmp) Nop. The actual mapping depends on your settings, but defaults to /tmp which is inside Cygwin installation root. Another option is to mount /tmp with 'usertemp' option, which would then redirect it to the user's %TEMP%. > when calling a WIN32 program > (e.g. cmd.exe). Is it possible, from bash or from Cygwin startup , to add > additional environment variable names so that they are also automatically > mapped in the same way? What is your question, exactly? What you want to achieve and what your actual observation compared to expected behavior? -- With best regards, Andrey Repin Friday, January 27, 2023 10:41:46 Sorry for my terrible english... -- 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 and TMPDIR mapping
Greetings, john daintree! > My understanding is that Cygwin maps $TMP and $TMPDIR (and probably others) > to a Windows form (/cygdrive/c/tmp -> C:\tmp) Nop. The actual mapping depends on your settings, but defaults to /tmp which is inside Cygwin installation root. Another option is to mount /tmp with 'usertemp' option, which would then redirect it to the user's %TEMP%. > when calling a WIN32 program > (e.g. cmd.exe). Is it possible, from bash or from Cygwin startup , to add > additional environment variable names so that they are also automatically > mapped in the same way? What is your question, exactly? What you want to achieve and what your actual observation compared to expected behavior? -- With best regards, Andrey Repin Friday, January 27, 2023 10:41:46 Sorry for my terrible english... -- 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
TMP and TMPDIR mapping
Hi My understanding is that Cygwin maps $TMP and $TMPDIR (and probably others) to a Windows form (/cygdrive/c/tmp -> C:\tmp) when calling a WIN32 program (e.g. cmd.exe). Is it possible, from bash or from Cygwin startup , to add additional environment variable names so that they are also automatically mapped in the same way? Thanks /John -- 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 5/6] Cygwin: testsuite: In pathconf01 use the temporary directory instead of "/tmp"
In pathconf01 use the temporary directory, instead of "/tmp" (which may not
exist).
---
winsup/testsuite/winsup.api/ltp/pathconf01.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/winsup/testsuite/winsup.api/ltp/pathconf01.c
b/winsup/testsuite/winsup.api/ltp/pathconf01.c
index 466875f21..990e6defe 100644
--- a/winsup/testsuite/winsup.api/ltp/pathconf01.c
+++ b/winsup/testsuite/winsup.api/ltp/pathconf01.c
@@ -117,6 +117,7 @@
extern void setup();
extern void cleanup();
+extern char *TESTDIR;
@@ -127,7 +128,7 @@ extern int Tst_count; /* Test Case counter
for tst_* routines */
int exp_enos[]={0, 0};
int i;
-const char *path = "/tmp";
+const char *path;
struct pathconf_args
{
@@ -157,6 +158,9 @@ main(int ac, char **av)
if ( (msg=parse_opts(ac, av, (option_t *) NULL, NULL)) != (char *) NULL )
tst_brkm(TBROK, cleanup, "OPTION PARSING ERROR - %s", msg);
+tst_tmpdir();
+path = TESTDIR;
+
/***
* perform global setup for test
***/
@@ -208,6 +212,8 @@ main(int ac, char **av)
/***
* cleanup and exit
***/
+tst_rmdir();
+
cleanup();
return 0;
--
2.37.2
RE: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock"
-Original Message- From: Cygwin On Behalf Of rt...@sciencetools.com Sent: 18 November 2020 22:03 To: cygwin@cygwin.com Subject: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock" Hey everyone, SUPER long time Cygwin user, seldom need help, and my versions are all ancient now and I can't upgrade, I don't think. I'm on Windows 7 and am stuck there. Other version data follows. Everything had been working fine for years, then I had a system crash and on restart, this is the only error I can find. When run from the Cygwin shell command line, it goes like this: $ XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.19.2.0 OS: CYGWIN_NT-6.1 Okrasa 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.19.2-1 built 2017-03-09 XWin was started with the following command line: XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp (EE) Fatal server error: (EE) Could not create lock file in /tmp/.tX0-lock winDeinitMultiWindowWM - Noting shutdown in progress $ I tried with window IDs 1 and 2 instead of zero but these didn't work either. Later, while busy with other things, there was a power failure for the facility and when the power came back on, of course the system had rebooted so I tried again and got the same thing. ...Somehow early in my testing to get this going, without intentionally doing anything else, I noticed the error changed from "Could not create lock file in", to "Can't read lock file /tmp/.X0-lock". Looking for the directory previously mentioned, it wasn't there so I decided to try and create that directory. When I do that, the error goes back to "Could not create lockfile in". ... I wonder if I created it with the right ownership and permissions, so I tried several things with no success. ...I'm rather desperate to fix this as this feature has become a key tool for this particular system. Ideas? Help? Thanks, RT Also a long-time W7 user: try deleting everything X-relevant under /tmp/ (in my case .X11-unix/ and its contents) and then $ run XWin -clipboard -nolock -multiwindow I know, simpler than yours - but this has evolved over the years, replacing earlier more complex command lines which suddenly broke, usually after some relevant update. Any good? BUT NB I am Cygwin-current - what's your difficulty with updating? Fergus -- 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
Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock"
Hey everyone, SUPER long time Cygwin user, seldom need help, and my versions are all ancient now and I can't upgrade, I don't think. I'm on Windows 7 and am stuck there. Other version data follows. Everything had been working fine for years, then I had a system crash and on restart, this is the only error I can find. When run from the Cygwin shell command line, it goes like this: -- $ XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.19.2.0 OS: CYGWIN_NT-6.1 Okrasa 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.19.2-1 built 2017-03-09 XWin was started with the following command line: XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp (EE) Fatal server error: (EE) Could not create lock file in /tmp/.tX0-lock winDeinitMultiWindowWM - Noting shutdown in progress $ -- I tried with window IDs 1 and 2 instead of zero but these didn't work either. Later, while busy with other things, there was a power failure for the facility and when the power came back on, of course the system had rebooted so I tried again and got the same thing. ...Somehow early in my testing to get this going, without intentionally doing anything else, I noticed the error changed from "Could not create lock file in", to "Can't read lock file /tmp/.X0-lock". Looking for the directory previously mentioned, it wasn't there so I decided to try and create that directory. When I do that, the error goes back to "Could not create lockfile in". ... I wonder if I created it with the right ownership and permissions, so I tried several things with no success. ...I'm rather desperate to fix this as this feature has become a key tool for this particular system. Ideas? Help? Thanks, RT -- 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
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
> >> #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
Re: Sv: TMP/TEMP environment variable and /tmp
Greetings, Kristian Ivarsson via Cygwin!
> 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"
That's how it works. It's just that Cygwin provides /tmp aliasing as a mount
point option for a better usage experience.
See /etc/fstab - the usertemp FS pseudotype.
I.e.
none /tmp usertemp binary,nouser,posix=1 0 0
If yo have a different TMP (than TEMP), check your shell startup for any
redefinitions.
--
With best regards,
Andrey Repin
Sunday, September 20, 2020 10:16:54
Sorry for my terrible english...
--
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
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 cont
Re: TMP/TEMP environment variable and /tmp
>>>>>>>> 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
Re: TMP/TEMP environment variable and /tmp
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
Re: TMP/TEMP environment variable and /tmp
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: TMP/TEMP environment variable and /tmp
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: TMP/TEMP environment variable and /tmp
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: TMP/TEMP environment variable and /tmp
>>>>>> 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: TMP/TEMP environment variable and /tmp
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: Sv: TMP/TEMP environment variable and /tmp
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
Sv: TMP/TEMP environment variable and /tmp
> >>> 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
Re: TMP/TEMP environment variable and /tmp
Am 16.09.2020 um 13:12 schrieb Thomas Wolff: 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 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. A bigger part of the reason may have been what the result of that platform-dependent query would have been, back when the decision had to be made. For several releases you would have ended up with (your locally translated version of!) stupid old "Documents and Settings" as part of the pathname, and possibly some extra blanks and special characters from the user name, on top of that. And I for one really do not trust that a Unix temp directory can safely have white space in its name without breaking lots of tools' behavior in nastily interesting ways. IIRC it took until Windows 8 for Microsoft to finally own up to their error and change it to the profoundly less insane "Users". But by then it was too late, all the damage had been done already. -- 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
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.
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
Re: TMP/TEMP environment variable and /tmp
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.
--
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
TMP/TEMP environment variable and /tmp
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
--
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: Odd hang of cc1.exe *resolved. /tmp/cygwin1.dll. Apologies * cpp/gcc
Hi, On 7/5/20 1:44 pm, Shaddy Baddah wrote: Thanks. Yes, I am mapping my directory outside the cygwin directory tree, via /etc/fstab. I will certainly check the perms and see if they make a difference. However, you must admit, it is weird that running as.exe with path /usr/bin/as.exe does not break like running the same exe with path /usr/x86_64-pc-cygwin/bin/as.exe, out of the same /tmp directory, is inexplicable. And even if perms are involved, it's quite unexpected that spawning a Cygwin executable would behave in a very undesirable way. Whilst I am able to recover the situation with ctrl-d or ctrl-c in a console window (command prompt or ConEmu), under mintty, I get a total lock up if I try ctrl-d or ctrl-c. I can only recover my mintty session by avoiding ctrl-d/c and selectively killing processes via taskmgr (I think child of bash first, then the hung /usr/x86_64-pc-cygwin/bin/ process). I'll accept that my experience must be accounted for as an extreme corner case. But I feel satsified that I have documented it here, in case some silent observers have been experiencing like issues, and not reporting them. On the face of it, those users might have thought it was a problem with mintty, which I don't believe it is. And I want to clarify, I don't think Cygwin's DLL code is at fault at all. If my understanding is correct, there are all sorts of code segments in the DLL where an adjustment has to be made because a Windows API function does not behave consistently, or as per its documentation. I suspect this is an unidentified equivalent. I apologise if I've wasted anyone's time on this. I tried resetting the permissions on /tmp, and then on a hunch that some file in /tmp might be inducing the *alleged* (frivolously on my part) issue with Windows, I started removing files one by one. Eventually I noticed a copy of an old cygwin1.dll (actually a custom build of 2.10.0) and that of course was the culprit. And it makes sense now of course. /usr/bin/as (and cc1) are going to load cygwin1.dll in /usr/bin, which is consistent with bash/mintty etc, because it exists in the same directory as the executable. And of course, /tmp/cygwin1.dll was loaded as it was in the current directory, and the executable not being in /usr/bin meant that Windows wasn't using the colocated DLL as the first search result. I'm really sorry Cygwin community. I'll store this one in my memory banks, and hope there is no next time. -- Embarrassedly yours, Shaddy -- 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: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc
Hi Doug, On 7/5/20 11:19 am, Doug Henderson via Cygwin wrote: I think this is the essence of your problem. It looks like you are mapping you temporary directory outside the cygwin directory tree, Not sure how you are doing it. For me, I have TMP=/tmp and TEMP=/tmp in my cygwin environment. In my windows environment, i.e, when running cmd.exe, TEMP and TMP point to C:\Users\Doug\AppData\Local\Temp. I expect you will find that the windows permissions for your temp directory is different from the default /tmp. Check this using lsacl (A bash script found somewhere in this mailing list.) Or the file properties from windows explorer. In my case: $ ls -ld /tmp drwxrwxrwt+ 1 Admin None 0 May 6 18:51 /tmp/ $ ls -ld $(cygpath -u 'C:\Users\Doug\AppData\Local\Temp' ) drwxrwx---+ 1 Doug SYSTEM 0 May 6 18:50 /cygdrive/c/Users/Doug/AppData/Local/Temp/ $ lsacl /tmp [u::rwx,g::rwx,o::rwx/u::rwx,g::r-x,o::r-x] /tmp $ lsacl $(cygpath -u 'C:\Users\Doug\AppData\Local\Temp' ) [u::rwx,g::rwx,g:Administrators:rwx,m::rwx,o::---/u::rwx,g::rwx,g:SYSTEM:rwx,g:Administrators:rwx,m::rwx,o::---] /cygdrive/c/Users/Doug/AppData/Local/Temp I suggest you change your temporary directory to ./tmp, or align the permissions. Thanks. Yes, I am mapping my directory outside the cygwin directory tree, via /etc/fstab. I will certainly check the perms and see if they make a difference. However, you must admit, it is weird that running as.exe with path /usr/bin/as.exe does not break like running the same exe with path /usr/x86_64-pc-cygwin/bin/as.exe, out of the same /tmp directory, is inexplicable. And even if perms are involved, it's quite unexpected that spawning a Cygwin executable would behave in a very undesirable way. Whilst I am able to recover the situation with ctrl-d or ctrl-c in a console window (command prompt or ConEmu), under mintty, I get a total lock up if I try ctrl-d or ctrl-c. I can only recover my mintty session by avoiding ctrl-d/c and selectively killing processes via taskmgr (I think child of bash first, then the hung /usr/x86_64-pc-cygwin/bin/ process). I'll accept that my experience must be accounted for as an extreme corner case. But I feel satsified that I have documented it here, in case some silent observers have been experiencing like issues, and not reporting them. On the face of it, those users might have thought it was a problem with mintty, which I don't believe it is. And I want to clarify, I don't think Cygwin's DLL code is at fault at all. If my understanding is correct, there are all sorts of code segments in the DLL where an adjustment has to be made because a Windows API function does not behave consistently, or as per its documentation. I suspect this is an unidentified equivalent. -- Regards, Shaddy -- 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: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc
On Wed, 6 May 2020 at 08:34, Shaddy Baddah <> wrote: > On 29/4/20 10:38 pm, Shaddy Baddah wrote: > > > > … And only when run out of my /tmp (which is custom mapped btw). > > > > | /tmp$ ls -li /usr/bin/as.exe /usr/x86_64-pc-cygwin/bin/as.exe > | 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None > 5981696 Mar 15 15:16 /usr/bin/as.exe > | 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None > 5981696 Mar 15 15:16 /usr/x86_64-pc-cygwin/bin/as.exe > > > I think this is the essence of your problem. It looks like you are mapping you temporary directory outside the cygwin directory tree, Not sure how you are doing it. For me, I have TMP=/tmp and TEMP=/tmp in my cygwin environment. In my windows environment, i.e, when running cmd.exe, TEMP and TMP point to C:\Users\Doug\AppData\Local\Temp. I expect you will find that the windows permissions for your temp directory is different from the default /tmp. Check this using lsacl (A bash script found somewhere in this mailing list.) Or the file properties from windows explorer. In my case: $ ls -ld /tmp drwxrwxrwt+ 1 Admin None 0 May 6 18:51 /tmp/ $ ls -ld $(cygpath -u 'C:\Users\Doug\AppData\Local\Temp' ) drwxrwx---+ 1 Doug SYSTEM 0 May 6 18:50 /cygdrive/c/Users/Doug/AppData/Local/Temp/ $ lsacl /tmp [u::rwx,g::rwx,o::rwx/u::rwx,g::r-x,o::r-x] /tmp $ lsacl $(cygpath -u 'C:\Users\Doug\AppData\Local\Temp' ) [u::rwx,g::rwx,g:Administrators:rwx,m::rwx,o::---/u::rwx,g::rwx,g:SYSTEM:rwx,g:Administrators:rwx,m::rwx,o::---] /cygdrive/c/Users/Doug/AppData/Local/Temp I suggest you change your temporary directory to ./tmp, or align the permissions. HTH, Doug -- 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: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc
Hi,
On 29/4/20 10:38 pm, Shaddy Baddah wrote:
Matches what I see when I ctrl-d the *hung* 64-bit cc1.
At this point, I am going to back right off. I am fairly sure now this
is some form of BLODA. We do have something installed that logs all
commands run. And that is so sacred to our IT security team, I've
watched iterations of *hardening* of it, and the service can't be
stopped or the process killed as a Local admin.
Perhaps this is intercepting the process arguments and failing to
*proxy* them when it has recorded them.
I've requested our IT security team assist. I'll workaround this for the
moment. It's very unsettling when your foundations are constantly
shifting.
As I expected, I given very short shrift from the IT security
team. Not to worry. I tried a number of things, including running
Windows in safe mode, where seemingly these potential BLODA agents
aren't running. Nothing helped. Until...
I have to come to discover, it is not just cc1 being affected, it is
at least as running out of /usr/x86_64-pc-cygwin/bin that is
affected. And only when run out of my /tmp (which is custom mapped
btw).
Here is the absolutely bizarre and inexplicable example of the issue:
| ~$ /bin/as --help
| Usage: /bin/as [option...] [asmfile...]
| ...
| Report bugs to <http://www.sourceware.org/bugzilla/>
|
| ~$ /usr/x86_64-pc-cygwin/bin/as --help
| Usage: /usr/x86_64-pc-cygwin/bin/as [option...] [asmfile...]
| ...
| Report bugs to <http://www.sourceware.org/bugzilla/>
|
| ~$ cd /tmp
| /tmp$ /bin/as --help
| Usage: /bin/as [option...] [asmfile...]
| ...
| Report bugs to <http://www.sourceware.org/bugzilla/>
|
| /tmp$ /usr/x86_64-pc-cygwin/bin/as --help
|
| /tmp$
And just to be clear, as.exe is hardlinked at each path:
| /tmp$ ls -li /usr/bin/as.exe /usr/x86_64-pc-cygwin/bin/as.exe
| 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None
5981696 Mar 15 15:16 /usr/bin/as.exe
| 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None
5981696 Mar 15 15:16 /usr/x86_64-pc-cygwin/bin/as.exe
So obviously the /tmp mount must have some trait that is triggering
this. But I must use the word triggering, because I also built a debug
version of cygwin1.dll. And it seems clear to me that the problem is
in the sigproc code, called off of a spawn I believe, specifically
this:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sigproc.cc;h=7286e323815d75f771fba54d7797a3d36273a242;hb=81b34409985ce31415a1d994ef744e72cfb8c378#l1032
1031 sigproc_printf ("n %d, waiting for subproc_ready(%p) and child
process(%p)", n, w4[0], w4[1]);
1032 DWORD x = WaitForMultipleObjects (n, w4, FALSE, howlong);
1033 x -= WAIT_OBJECT_0;
1034 if (x >= n)
1035 {
For whatever reason, WaitForMultipleObjects() blocks within Cygwin
dll. The windows process is running, but obviously, the Cygwin process
is not fully formed (as I understand it, the pid is registered after
this call returns). ps doesn't show it.
Further, if I enter ctrl-d, WaitForMultipleObjects() returns, but as
per my earlier emails, behaves as if I had not given any arguments
(just like cc1 from my earlier emails).
At this point, it seems it has to be a Windows bug. It also could be a
way of calling WaitForMultipleObjects() which has worked in 99.9% of
cases, but based off of this article, needs some form of precheck
code:
https://groups.google.com/forum/#!topic/comp.programming.threads/3qtP79SkU64
| comp.programming.threads ›
| WaitForMultipleObjects never wakes up - Windows-bug?
...
| Bonita Montero
| 5/23/16
| I've got a solution for this problem.
| In the main-thread, simply wait for the semaphore and then for the
| event (in this order - or you're gonna deadlock) with WaitForSingle
| Object. That's not so efficitent, but works.
I don't understand the existing code well enough to know if this the
article is as relevant that it appears, at face value.
In any case, at least I have my solution for the moment. Avoid the
crutch of dumping a simple C program in /tmp and compiling. It is
going to end in tears.
--
Regards,
Shaddy
--
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: Cygcheck.out sent to list causes email to get blocked (was Re: unset TMP Variable issue)
On 2019-08-29 05:05, L A Walsh wrote: > On 2019/07/20 16:30, Nikos Balkanas wrote: >>> >>> Attached is the zipped cygcheck output with user names crossed out >>> > > Worry, but your attachment of the output never came through. Neither > did mind. > > Looks like the mailing list software discards cygcheck.out output now, > which > seems to make the error reporting process a bit broken? Emails may only have plain text attachments: add cygwin.com/org/net and sourceware.org to Thunderbird plain text domains max line length 80, 72, 64: Tools/Options/Composition/General/Send Options/Text Format/[X]Send as plain text Tools/Options/Composition/General/Send Options/[Convert to plain text] Tools/Options/Composition/General/Send Options/Plain Text Domains/Add/cygwin.com Tools/Options/Advanced/General/Config Editor/Search/wrap or the equivalent in other MUAs. -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygcheck.out sent to list causes email to get blocked (was Re: unset TMP Variable issue)
Seems so. However, I was lucky enough to fix my problem on my own:) BR, Nikos On Thu, Aug 29, 2019 at 2:05 PM L A Walsh wrote: > > On 2019/07/20 16:30, Nikos Balkanas wrote: > >> > >> Attached is the zipped cygcheck output with user names crossed out > >> > > Worry, but your attachment of the output never came through. Neither > did mind. > > Looks like the mailing list software discards cygcheck.out output now, > which > seems to make the error reporting process a bit broken? > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygcheck.out sent to list causes email to get blocked (was Re: unset TMP Variable issue)
On 2019/07/20 16:30, Nikos Balkanas wrote: >> >> Attached is the zipped cygcheck output with user names crossed out >> Worry, but your attachment of the output never came through. Neither did mind. Looks like the mailing list software discards cygcheck.out output now, which seems to make the error reporting process a bit broken? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: unset TMP Variable issue
Problem was windows line breaks:( On Sat, Jul 20, 2019 at 9:34 PM Nikos Balkanas wrote: > > According to cygwin setup instructions we have to unset certain > windows environment variables to prevent unpredictable windows > behavior. > When I try that in my ~/.bashrc > [...] > unset TMPDIR > unset TMP > unset TEMP > [...] > > I get: > ': not a valid identifier > ': not a valid identifier > ': not a valid identifier > > With the following input: > cygwin-> echo $TMP > /cygdrive/c/Users//AppData/Local/Temp > cygwin-> echo $TEMP > /cygdrive/c/Users//AppData/Local/Temp > cygwin-> echo $TMPDIR > > cygwin-> > > What does the error "': not a valid identifier" mean and how can I fix it? > > TIA > Nikos > > Attached is the zipped cygcheck output with user names crossed out -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: fstab /tmp usertemp error after Windows Update
Your TMP or TEMP environment variable is probably set to that value. Exit Cygwin, fix the environment variable and then go into Cygwin and check it. Dave > -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On > Behalf Of Jeff Howard > Sent: Tuesday, June 27, 2017 2:43 PM > To: cygwin@cygwin.com > Subject: EXT: fstab /tmp usertemp error after Windows Update > > Hello - > > After a recent Windows Update (and reboot) the following fstab entry we > used directly from the Cygwin documentation (https://cygwin.com/cygwin- > ug-net/using.html) is no longer working. After digging a little deeper, it > appears to be attempting to mount /tmp to a directory that doesn't exist on > my local filesystem. > > I can of course create the directory in my temp folder, but that would defeat > the purpose in our multi-user environment. Since we're in a multi-user > environment, our intention is for each user to seamlessly mount /tmp to > their own temporary folder to prevent permissions issues. I also updated > the Cygwin binaries for good measure, and the issue still persists. > > Examples of my fstab and output from "mount" are in-line below. Note that > the directory "/3" does not exist in my local temp folder - > "C:/Users/Jeff/AppData/Local/Temp" does not exist in my local temp folder: > > $ cat fstab > # /etc/fstab > # > #This file is read once by the first process in a Cygwin process tree. > #To pick up changes, restart all Cygwin processes. For a description > #see https://cygwin.com/cygwin-ug-net/using.html#mount-table > > # This is default anyway: > none /cygdrive cygdrive binary,posix=0,user 0 0 > none /tmp usertemp binary,posix=0 0 0 > > Jeff@CM /etc > $ mount > C:/Users/Jeff/AppData/Local/Temp/3 on /tmp type ntfs > (binary,posix=0,usertemp) > C:/cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/cygwin on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) > E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto) > > > - Jeff > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
fstab /tmp usertemp error after Windows Update
Hello - After a recent Windows Update (and reboot) the following fstab entry we used directly from the Cygwin documentation (https://cygwin.com/cygwin-ug-net/using.html) is no longer working. After digging a little deeper, it appears to be attempting to mount /tmp to a directory that doesn't exist on my local filesystem. I can of course create the directory in my temp folder, but that would defeat the purpose in our multi-user environment. Since we're in a multi-user environment, our intention is for each user to seamlessly mount /tmp to their own temporary folder to prevent permissions issues. I also updated the Cygwin binaries for good measure, and the issue still persists. Examples of my fstab and output from "mount" are in-line below. Note that the directory "/3" does not exist in my local temp folder - "C:/Users/Jeff/AppData/Local/Temp" does not exist in my local temp folder: $ cat fstab # /etc/fstab # #This file is read once by the first process in a Cygwin process tree. #To pick up changes, restart all Cygwin processes. For a description #see https://cygwin.com/cygwin-ug-net/using.html#mount-table # This is default anyway: none /cygdrive cygdrive binary,posix=0,user 0 0 none /tmp usertemp binary,posix=0 0 0 Jeff@CM /etc $ mount C:/Users/Jeff/AppData/Local/Temp/3 on /tmp type ntfs (binary,posix=0,usertemp) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto) - Jeff -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]
2015-04-11 2:35 GMT+02:00 LRN lrn1...@gmail.com: On 11.04.2015 0:55, Frank Fesevur wrote: 2015-04-10 22:38 GMT+02:00 Andrew DeFaria: $ man 5 crontab See @reboot Never used it but I assume it will run after cron service is started. Yes it is. After reading again the man, reboot is referred to the start / restart of the cron service itself, not to the status of the reboot machine. I haven't used it either, but I saw it there. Makes you wonder what would happen if you simply restarted the service or stopped it and then started it again. Have cron installed on my laptop so I just tested. And yes, that is how @reboot works on Cygwin. It runs the job right after the cron daemon is started, regardless how many times you restart the service. On Linux it seems to detect that the system really was rebooted. Or, if you have a lot of memory, install ImDisk, create a disk and move temp directory onto it. It's guaranteed to not to survive reboots. Also, it's probably faster than having temp directory on a real disk. -- O ascii ribbon - stop html email! - www.asciiribbon.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]
On 4/10/2015 1:19 AM, Frank Fesevur wrote: 2015-04-10 9:49 GMT+02:00 Kizito Porta Balanyà: I'm wondering how cron knows when a machine is rebooted. What does cron check? Which parameter / file? Do you know it? $ man 5 crontab See @reboot Never used it but I assume it will run after cron service is started. Regards, Frank I haven't used it either, but I saw it there. Makes you wonder what would happen if you simply restarted the service or stopped it and then started it again. -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]
2015-04-10 22:38 GMT+02:00 Andrew DeFaria: $ man 5 crontab See @reboot Never used it but I assume it will run after cron service is started. I haven't used it either, but I saw it there. Makes you wonder what would happen if you simply restarted the service or stopped it and then started it again. Have cron installed on my laptop so I just tested. And yes, that is how @reboot works on Cygwin. It runs the job right after the cron daemon is started, regardless how many times you restart the service. On Linux it seems to detect that the system really was rebooted. Regards, Frank -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]
On 11.04.2015 0:55, Frank Fesevur wrote: 2015-04-10 22:38 GMT+02:00 Andrew DeFaria: $ man 5 crontab See @reboot Never used it but I assume it will run after cron service is started. I haven't used it either, but I saw it there. Makes you wonder what would happen if you simply restarted the service or stopped it and then started it again. Have cron installed on my laptop so I just tested. And yes, that is how @reboot works on Cygwin. It runs the job right after the cron daemon is started, regardless how many times you restart the service. On Linux it seems to detect that the system really was rebooted. Or, if you have a lot of memory, install ImDisk, create a disk and move temp directory onto it. It's guaranteed to not to survive reboots. Also, it's probably faster than having temp directory on a real disk. -- O ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]
On 4/9/2015 5:51 AM, cyg Simple wrote: From: Jim Reisert AD1C Wouldn't it be nice if Cygwin cleaned up the /tmp directory each time the computer is re-booted? I don't know how that would work in real life, however. Simply create a scheduled task to execute a windows batch file on system start that changes directory to the Cygwin /bin directory and executes sh -c 'rm -f /tmp/*'. -- cyg Simple Or use cron... -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Clean up /tmp on system reboot [was: Xorg server always starting up on DISPLAY 3.0]
From: Jim Reisert AD1C Wouldn't it be nice if Cygwin cleaned up the /tmp directory each time the computer is re-booted? I don't know how that would work in real life, however. Simply create a scheduled task to execute a windows batch file on system start that changes directory to the Cygwin /bin directory and executes sh -c 'rm -f /tmp/*'. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 15, 2014, at 10:55 AM, Lee ler...@gmail.com wrote: On 11/13/14, Warren Young wrote: I installed Cygwin with my regular user account, You're doing it wrong. Install Cygwin using an admin account and regular user accounts are not allowed write access to system files/directories: While my idea does have applicability to multi-user Windows systems, I also want it to work without using Admin gymnastics on a single-user Windows system. That is, I want this: $ echo -n /usr/bin/vi to fail just as this does: $ echo -n /cygdrive/c/Windows/notepad.exe -bash: /cygdrive/c/Windows/notepad.exe: Permission denied I want them both to fail for the same reason: normal users — whether they are members of group Administrators or not — have no business writing to system files. Only the installer process (Cygwin Setup in this case) should be able to do that. For what it’s worth: $ cd /cygdrive/c/Windows $ icacls notepad.exe notepad.exe NT SERVICE\TrustedInstaller:(F) BUILTIN\Administrators:(RX) NT AUTHORITY\SYSTEM:(RX) BUILTIN\Users:(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Sat, Nov 15, 2014 at 1:41 PM, Lee wrote: On 11/15/14, Jeffrey Altman wrote: On 11/15/2014 12:55 PM, Lee wrote: So, just because I installed Cygwin with my regular user account, You're doing it wrong. Install Cygwin using an admin account and regular user accounts are not allowed write access to system files/directories: This feels really wrong to me. If installing Cygwin under a non-admin account results in a potential security vulnerability, then the installer should be taking that into account. I would argue that no, the installer should _not_ take that into account. If someone wants to install cygwin under their regular userid, why should the installer try to work around that? The files are installed with the correct permissions if the windows admin has an administrator account for doing admin chores a regular user account for doing day to day user tasks. Because a user who is using a corporate laptop with administrator accounts locked down would not be able to install Cygwin. Because a user who is used to having ownership of the files he installs would become frustrated that he could not remove Cygwin by simply opening the Windows explorer, picking his way to the Cygwin root folder, right clicking it and saying Delete. Because this list would become overrun with queries of why can't I add a program from an archive to the /usr/bin directory or remove or ... An install Only for the user should not create such locked down control of the system without asking. Some users tend to know what to do and what not to do and do not want the extra measures to protect themselves. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On 11/13/14, Warren Young wrote: On Nov 13, 2014, at 2:33 AM, Corinna Vinschen wrote: On Nov 12 17:19, Warren Young wrote: I'm not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What strong ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe Install cygwin as an admin users don't get write access: $ ls -l /bin/ls.exe -rwxr-xr-x 1 root None 101902 Feb 6 2012 /bin/ls.exe The same file's permissions, from Windows' perspective: http://etr-usa.com/cygwin/ls-perms.png So, just because I installed Cygwin with my regular user account, You're doing it wrong. Install Cygwin using an admin account and regular user accounts are not allowed write access to system files/directories: $ cd /bin /bin $ touch foo touch: cannot touch `foo': Permission denied /bin $ cd /usr /usr $ touch foo touch: cannot touch `foo': Permission denied I get permission to rewrite ls.exe. This is not a good thing, In certain circumstances you're right; not a good thing. If you have an admin account on the machine, why didn't you install cygwin using that account have the permissions set correctly in the first place? In other circumstances, like not having an admin account, it's nice being able to install use cygwin as a regular user vs. not having access to cygwin at all. if our goal is to make Cygwin work like Linux while working *within* the Windows environment. IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, N! Please, do not do that by default. If nothing else, directory names with embedded spaces should be treated like toxic waste. and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case. Try installing cygwin as an admin. I suspect you'll get most, if not all, of what you're asking for. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On 11/15/2014 12:55 PM, Lee wrote: So, just because I installed Cygwin with my regular user account, You're doing it wrong. Install Cygwin using an admin account and regular user accounts are not allowed write access to system files/directories: This feels really wrong to me. If installing Cygwin under a non-admin account results in a potential security vulnerability, then the installer should be taking that into account. Applications that behave differently depending upon how they are installed should have in the installer an option for * install for all users (requires administrator) * install for the current user Where install for current user installs the application configured so that the current user account (and not others) can use it. Just my two cents. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On 11/15/14, Jeffrey Altman jalt...@secure-endpoints.com wrote: On 11/15/2014 12:55 PM, Lee wrote: So, just because I installed Cygwin with my regular user account, You're doing it wrong. Install Cygwin using an admin account and regular user accounts are not allowed write access to system files/directories: This feels really wrong to me. If installing Cygwin under a non-admin account results in a potential security vulnerability, then the installer should be taking that into account. I would argue that no, the installer should _not_ take that into account. If someone wants to install cygwin under their regular userid, why should the installer try to work around that? The files are installed with the correct permissions if the windows admin has an administrator account for doing admin chores a regular user account for doing day to day user tasks. Applications that behave differently depending upon how they are installed It's the file permissions that are different. As far as I can tell, cygwin behaves the same when installed by a user for the current user when installed as an admin for all users. should have in the installer an option for * install for all users (requires administrator) * install for the current user Which the cygwin installer does do. It's up to the user that wants the more secure file permissions to install cygwin using an admin account have another account for normal day to day use. Best Regards, Lee Where install for current user installs the application configured so that the current user account (and not others) can use it. Just my two cents. Jeffrey Altman -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Wed, Nov 12, 2014 at 5:16 PM, Warren Young wrote: On Nov 12, 2014, at 2:53 PM, cyg Simple wrote: On Wed, Nov 12, 2014 at 1:00 PM, Warren Young wrote: I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally. What local changes/installations get lost? Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration. On Wed, Nov 12, 2014 at 5:21 PM, Andrey Repin wrote: Greetings, cyg Simple! What local changes/installations get lost? What get lost, if you nuke Cygwin folder in default installation? Everything. Every single piece you could think about. Cygwin cannot prevent stupidity. These nuked files should be recoverable by a restore process from a backup. However, place your files that setup doesn't control in other directories and use /etc/fstab to map them. For instance I have a c:/opt directory where I install many applications. I also have a c:/mnt directory where I put things like c:/mnt/home and mount that to /home. I can have two different instance of Cygwin running with a common $HOME. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 12 17:19, Warren Young wrote: On Nov 12, 2014, at 3:43 PM, Andrew DeFaria and...@defaria.com wrote: On 11/12/2014 2:16 PM, Warren Young wrote: What local changes/installations get lost? Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration. Technically user files can exist anywhere in the file system All the more reason to move to a world where it’s possible to start securing /usr/bin, /usr/lib, /usr/share… so that only setup.exe can write to it. I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What strong ACLs? Setup creates the files with standard POSIX permissions. Which permissions are too open from your POV? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQ3JF4ytkeu.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 12 11:00, Warren Young wrote: I didn’t want to derail the discussion about the future of /home with this, so I’m starting a new thread. I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally. Further design principles follow from this: - User data should live in directories that those users are normally allowed to write to. - Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to. - Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere. - If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include. This /etc/fstab addition mostly accomplishes that: c:/Users/Public/Cygwin/var /var ntfs auto 0 0 c:/Users/Public/Cygwin/usr/local /usr/local ntfs auto 0 0 c:/Users/Public/Cygwin/tmp /tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /usr/tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /var/tmp ntfs notexec 0 0 I propose that this or something like it be added to the default fstab. No. This would even break Setup right now. Also, Users\Public doesn't exist on XP/2K3 so this needs additional logic as long as we support XP/2K3. I'm not entirely opposed to such an idea. But... - definitely not this year. or even the first half of next year. We have to consolidate the changes to account handling first, and, right now, I'm basically the only developer working on the Cygwin core more than just doing small patches. - A change like this should probably work in conjunction with a setting in the Setup GUI. - So this requires changes in Setup and Cygwin. I'm not going to do that, unless I have more support on the coding side, and more participation of serious coders on the cygwin-developer ML. - Did I mention that stuff like this would be much less hassle if we had more people doing some coding? The only thing remaining in c:\cygwin that can’t be moved in this way — but which it would be nice to — is /etc. If you try, you will find that it makes Cygwin asplode; cygwin1.dll needs to find $cygbindir/../etc in order to find /etc/fstab, at the least. That's documented behaviour, and it's an obvious chicken/egg problem, isn't it? fstab is the file *defining* mount points, so Cygwin can't use the mount points in fstab to find etc/fstab Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDvCZRNLHzF.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 2:33 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 12 17:19, Warren Young wrote: I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What strong ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png So, just because I installed Cygwin with my regular user account, I get permission to rewrite ls.exe. This is not a good thing, if our goal is to make Cygwin work like Linux while working *within* the Windows environment. IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 14:09, Warren Young wrote: On Nov 13, 2014, at 2:33 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 12 17:19, Warren Young wrote: I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What strong ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. However, this isn't really a problem. The group permissions are apparently faked by Cygwin, they don't reflect the reality. I just don't remember why this is done, it's probably old. Have to check... So, just because I installed Cygwin with my regular user account, I get permission to rewrite ls.exe. This is not a good thing, if our goal is to make Cygwin work like Linux while working *within* the Windows environment. IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, No, sorry, but no. We're certainly not going to turn everything upside down installation-wise. If you want Cygwin installed into Program Files, just change it in the GUI. and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case. BTDT. The code is still in Setup, just doesn't run anymore. The idea was to install with user and group set to Administator/ Administrators, but we had some complaints and the code got deactivated. We can reactivate the Administrators group, but that still requires to run Setup elevated. It doesn't work when running under a non-admin account. However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpUScr7NJVhJ.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 2:55 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 12 11:00, Warren Young wrote: I propose that this or something like it be added to the default fstab. No. This would even break Setup right now. I’m guessing this is because setup.exe doesn’t know what to do with a redirected /var and /usr/local on the first install, when /etc/fstab doesn’t exist yet? I assume setup.exe does obey /etc/fstab on subsequent installs. If not, I can see that this will break the installation of any package that puts files in either location. I don’t see that the */tmp changes would bother setup.exe. None of these problems seem difficult. Doesn’t setup.exe write the initial /etc/fstab, and so is in a position to know what it will contain on first install? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 2:30 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 13 14:09, Warren Young wrote: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. $ icacls ls.exe ls.exe MOSSYMAZE\Warren:(F) MOSSYMAZE\Warren:(RX) Everyone:(RX) It doesn't work when running under a non-admin account. Every other Windows setup program is playing by that same restriction. However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 22:30, Corinna Vinschen wrote: On Nov 13 14:09, Warren Young wrote: On Nov 13, 2014, at 2:33 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 12 17:19, Warren Young wrote: I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What strong ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. However, this isn't really a problem. The group permissions are apparently faked by Cygwin, they don't reflect the reality. I just don't remember why this is done, it's probably old. Have to check... Btw., I never saw this happen. Did you install for just you, or in a non-elevated Setup? In my case the permissions make at least sense, even if my own account still has full access: $ ls -l /bin/ls.exe -rwxr-xr-x 1 corinna vinschen 116253 Oct 13 18:12 /bin/ls.exe Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpouBUUItxDj.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 14:39, Warren Young wrote: On Nov 13, 2014, at 2:30 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 13 14:09, Warren Young wrote: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. $ icacls ls.exe ls.exe MOSSYMAZE\Warren:(F) MOSSYMAZE\Warren:(RX) Everyone:(RX) It doesn't work when running under a non-admin account. Every other Windows setup program is playing by that same restriction. Setup tries to install with (explicit) POSIX permissions, not with (inherited) Windows permissions. It's not quite the same thing. However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user? In a corporate model this might make sense, but for the home user? I'm not so sure about SYSTEM, though. Administrator/Administrators sounds right to me. SYSTEM? Hmm. As I said, at one point back in the early 1.7 days setup did something like that, but we got complaints. I don't remember the details. But if we do something like that again, it should be configurable. Maybe the Just Me/All users choice is sufficient if explained sufficiently in the GUI? Also, who's going to do that? The coding part, I mean. Lots of what's required is already in setup, but I can't write it often enough (it's an obsession probably): I would be very glad for developers not shy making their hands dirty. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5uYM3TRCbt.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 3:09 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Did you install for just you, I just made a fresh install into c:\zz, accepting all the defaults in setup.exe, so it installed for everyone. I got the same result as my preexisting install. Perhaps this is helpful: $ id uid=1000(Warren) gid=513(None) groups=513(None),559(Performance Log Users),545(Users) Apparently I am a member of both None and Users, whatever that means. or in a non-elevated Setup? I did these tests on a Windows 10 technical preview VM with UAC left in its default setting. I did get the blue and yellow UAC dimmed desktop dialog when running setup.exe, so I assume it managed to elevate itself. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 14:30, Warren Young wrote: On Nov 13, 2014, at 2:55 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 12 11:00, Warren Young wrote: I propose that this or something like it be added to the default fstab. No. This would even break Setup right now. I’m guessing this is because setup.exe doesn’t know what to do with a redirected /var and /usr/local on the first install, when /etc/fstab doesn’t exist yet? I assume setup.exe does obey /etc/fstab on subsequent installs. If not, I can see that this will break the installation of any package that puts files in either location. I don’t see that the */tmp changes would bother setup.exe. None of these problems seem difficult. Doesn’t setup.exe write the initial /etc/fstab, and so is in a position to know what it will contain on first install? Perhaps, but I don't want to make such changes short-term, and I don't want to enforce such a big change in directory layout. This has to be made configurable in the GUI. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpP1YS7fnVuN.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 15:20, Warren Young wrote: On Nov 13, 2014, at 3:09 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Did you install for just you, I just made a fresh install into c:\zz, accepting all the defaults in setup.exe, so it installed for everyone. I got the same result as my preexisting install. Perhaps this is helpful: $ id uid=1000(Warren) gid=513(None) groups=513(None),559(Performance Log Users),545(Users) Apparently I am a member of both None and Users, whatever that means. That's normal. No idea what they thought by introducing the local None group. It's your primary group with every local SAM account, unchangable in the user management. or in a non-elevated Setup? I did these tests on a Windows 10 technical preview VM with UAC left in its default setting. I did get the blue and yellow UAC dimmed desktop dialog when running setup.exe, so I assume it managed to elevate itself. Weird. I wonder why the ACL doesn't contain your primary group. Setup installs all files with explicit ACL containing entries for you, your primary group, and Everyone. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFWBWx55jeZ.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, Warren Young! I propose that this or something like it be added to the default fstab. No. This would even break Setup right now. I’m guessing this is because setup.exe doesn’t know what to do with a redirected /var and /usr/local on the first install, when /etc/fstab doesn’t exist yet? I assume setup.exe does obey /etc/fstab on subsequent installs. If not, I can see that this will break the installation of any package that puts files in either location. I can't see, why it ever should care about /etc/fstab at all. The postinstall scripts - they do, but again, they run in cygwin environment, not native. I don’t see that the */tmp changes would bother setup.exe. None of these problems seem difficult. Doesn’t setup.exe write the initial /etc/fstab, and so is in a position to know what it will contain on first install? Even if it does, there's no reason to read it on subsequent updates. The expectation is that the directory tree is in one place. If you really want to scatter it, use native tools. It is possible and way less intrusive. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, 01:34 Sorry for my terrible english...
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, Corinna Vinschen! However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user? In a corporate model this might make sense, but for the home user? I'm not so sure about SYSTEM, though. Administrator/Administrators sounds right to me. SYSTEM? NT SERVICE\TrustedInstaller . At least that's what many of the apps installed with. @ /c/Program Files/DVD Maker $ icacls DVDMaker.exe | iconv -f cp866 DVDMaker.exe NT SERVICE\TrustedInstaller:(F) BUILTIN\Administrators:(RX) NT AUTHORITY\SYSTEM:(RX) BUILTIN\Users:(RX) Not all, though. @ /c/Program Files/Opera $ icacls.exe opera.exe | iconv -f cp866 opera.exe NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) Hmm. As I said, at one point back in the early 1.7 days setup did something like that, but we got complaints. I don't remember the details. But if we do something like that again, it should be configurable. Maybe the Just Me/All users choice is sufficient if explained sufficiently in the GUI? It's interested to know, what these complaints were about exactly. I was away from the list, when transition to 1.7 occured. Also, who's going to do that? The coding part, I mean. Lots of what's required is already in setup, but I can't write it often enough (it's an obsession probably): I would be very glad for developers not shy making their hands dirty. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, 02:02 Sorry for my terrible english...
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, Corinna Vinschen! Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. However, this isn't really a problem. The group permissions are apparently faked by Cygwin, they don't reflect the reality. I just don't remember why this is done, it's probably old. Have to check... Btw., I never saw this happen. Did you install for just you, or in a non-elevated Setup? In my case the permissions make at least sense, even if my own account still has full access: $ ls -l /bin/ls.exe -rwxr-xr-x 1 corinna vinschen 116253 Oct 13 18:12 /bin/ls.exe Curious. Same for me. Win7/64 with 64-bit Cygwin default (elevated) install. $ LANG=C ls -l /bin/ls -rwxr-xr-x 1 anrdaemon None 116253 Oct 13 19:12 /bin/ls $ LANG=C ls -l /bin/ls.exe -rwxr-xr-x 1 anrdaemon None 116253 Oct 13 19:12 /bin/ls.exe -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, 02:13 Sorry for my terrible english...
Re: /usr/local, /var and */tmp in c:\Users\Public
Hi, On 14/11/14 08:30, Corinna Vinschen wrote: On Nov 13 14:09, Warren Young wrote: On Nov 13, 2014, at 2:33 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 12 17:19, Warren Young wrote: I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What strong ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. However, this isn't really a problem. The group permissions are apparently faked by Cygwin, they don't reflect the reality. I just don't remember why this is done, it's probably old. Have to check... So, just because I installed Cygwin with my regular user account, I get permission to rewrite ls.exe. This is not a good thing, if our goal is to make Cygwin work like Linux while working *within* the Windows environment. IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, No, sorry, but no. We're certainly not going to turn everything upside down installation-wise. If you want Cygwin installed into Program Files, just change it in the GUI. and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case. BTDT. The code is still in Setup, just doesn't run anymore. The idea was to install with user and group set to Administator/ Administrators, but we had some complaints and the code got deactivated. We can reactivate the Administrators group, but that still requires to run Setup elevated. It doesn't work when running under a non-admin account. However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. If you read back through some of my emails to this list, you'll see that this is exactly the setup I adopted some time back. It is also why I contributed the -B switch to setup. What the OP is asking for has always been available. And it is analogous with Unix. What I do is: 1) create a non-admin user named portapps. 2) cmd 3) runas /user:portapps cmd 4) as portapps, run c:\Program Files\7zip\7zFM to give me a graphical way to navigate the filesystem and create folders. 5) Create a folder c:\Users\Public\portapps. 6) Adjust the permissions on that folder so that inheritance from c:\Users\Public is broken, and inherited permissions with portapps FullControl and Everyone read/execute (I'm talking Windows perms here). 7) Now I run setup-x86(_64) -B still as portapps from cmd, install to c:\User\Public\portapps\cygwin. 8) That's it. Now my regular user can run c:\User\Public\portapps\cygwin\bin\mintty - and cannot accidentally overwrite /bin, /etc or anything like that. All software administration (install, /etc config) is done via portapps user. 9) This is no different to unix/linux, where you'd have to do sudo apt-get install, or sudo yum install, or sudo vi /etc/profile etc portapps is almost equal to root. 10) If you want to do Windows privileged stuff, you'll have to run those in an elevated mintty. Of course there is still the danger of overwriting /bin there. But if you are limiting doing that to just things like ssh-host-config etc, than it's fine. Also best to have a separate admin account to your account if possible. -- Regards, Shaddy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
/usr/local, /var and */tmp in c:\Users\Public
I didn’t want to derail the discussion about the future of /home with this, so I’m starting a new thread. I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally. Further design principles follow from this: - User data should live in directories that those users are normally allowed to write to. - Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to. - Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere. - If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include. This /etc/fstab addition mostly accomplishes that: c:/Users/Public/Cygwin/var /var ntfs auto 0 0 c:/Users/Public/Cygwin/usr/local /usr/local ntfs auto 0 0 c:/Users/Public/Cygwin/tmp /tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /usr/tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /var/tmp ntfs notexec 0 0 I propose that this or something like it be added to the default fstab. It should apply to an existing setup without trouble. If you already have things in /var and /usr/local, you should copy those trees over first. The only thing remaining in c:\cygwin that can’t be moved in this way — but which it would be nice to — is /etc. If you try, you will find that it makes Cygwin asplode; cygwin1.dll needs to find $cygbindir/../etc in order to find /etc/fstab, at the least. Attempting to create a “shadow /etc” — vaguely like how Linux’s initrd works — also failed here, but it doesn’t seem like a good idea to do this anyway. It means you now have to remember which of the two etc dirs to edit files in, a management hassle I don’t want. (Anyone who uses FreeBSD with Ports installed knows this pain, with /etc and /usr/local/etc. In Cygwin, it would be /etc and /cygdrive/c/cygwin/etc.) Are there any directories I have missed? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Wed, Nov 12, 2014 at 1:00 PM, Warren Young wrote: I didn’t want to derail the discussion about the future of /home with this, so I’m starting a new thread. I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally. What local changes/installations get lost? Further design principles follow from this: - User data should live in directories that those users are normally allowed to write to. - Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to. - Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere. - If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include. This /etc/fstab addition mostly accomplishes that: c:/Users/Public/Cygwin/var /var ntfs auto 0 0 c:/Users/Public/Cygwin/usr/local /usr/local ntfs auto 0 0 c:/Users/Public/Cygwin/tmp /tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /usr/tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /var/tmp ntfs notexec 0 0 I propose that this or something like it be added to the default fstab. Please NO not by default or offering an option. A back end tool maybe in cygutils that can be run manually. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 12, 2014, at 2:53 PM, cyg Simple cygsim...@gmail.com wrote: On Wed, Nov 12, 2014 at 1:00 PM, Warren Young wrote: I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally. What local changes/installations get lost? Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration. Step 4 in the recommended uninstallation sequence[1] doesn't warn about this. I guess the thought there is that if you’re uninstalling Cygwin, you probably just installed it recently and decided you don’t want it. Apparently those of us who have been using Cygwin for years and just need to do a clean reinstall for some reason are expected to know enough not to take step 4 too literally. (Indeed, I have never nuked myself this way. Still, it seems a bit of an oversight.) Please NO not by default or offering an option. A back end tool maybe in cygutils that can be run manually. Are you just asking me not to move your cheese[2], or do you have a specific problem with this, which we could discuss? How does it help you to have user files intermixed with system files? Do you save documents into c:\Program Files, too? [1] https://cygwin.com/faq/faq.html#faq.setup.uninstall-all [2] https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, cyg Simple! I didn’t want to derail the discussion about the future of /home with this, so I’m starting a new thread. I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally. What local changes/installations get lost? What get lost, if you nuke Cygwin folder in default installation? Everything. Every single piece you could think about. Further design principles follow from this: - User data should live in directories that those users are normally allowed to write to. - Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to. - Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere. - If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include. This /etc/fstab addition mostly accomplishes that: c:/Users/Public/Cygwin/var /var ntfs auto 0 0 c:/Users/Public/Cygwin/usr/local /usr/local ntfs auto 0 0 c:/Users/Public/Cygwin/tmp /tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /usr/tmp ntfs notexec 0 0 c:/Users/Public/Cygwin/tmp /var/tmp ntfs notexec 0 0 I propose that this or something like it be added to the default fstab. Please NO not by default or offering an option. A back end tool maybe in cygutils that can be run manually. Give one good reason, other than impulsive screaming? -- WBR, Andrey Repin (anrdae...@yandex.ru) 13.11.2014, 01:19 Sorry for my terrible english...
Re: /usr/local, /var and */tmp in c:\Users\Public
On 11/12/2014 2:16 PM, Warren Young wrote: What local changes/installations get lost? Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration. Technically user files can exist anywhere in the file system, including C:\cygwin or /etc, /var, etc., or they could be put directly into /bin, /usr or /usr/sbin or whatever. You're just saying that *traditionally* these are the areas that *smart* users limit their local changes too. It's a nice guideline but there are no guarantees... Apparently those of us who have been using Cygwin for years and just need to do a clean reinstall for some reason are expected to know enough not to take step 4 too literally. I've been using Cygwin since 2003 (does that qualify me?) and have never feel the need to reinstall. However, as a contractor I've often had the need to install again... -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 12, 2014, at 3:43 PM, Andrew DeFaria and...@defaria.com wrote: On 11/12/2014 2:16 PM, Warren Young wrote: What local changes/installations get lost? Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration. Technically user files can exist anywhere in the file system All the more reason to move to a world where it’s possible to start securing /usr/bin, /usr/lib, /usr/share… so that only setup.exe can write to it. I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. Apparently those of us who have been using Cygwin for years and just need to do a clean reinstall for some reason are expected to know enough not to take step 4 too literally. I've been using Cygwin since 2003 (does that qualify me?) and have never feel the need to reinstall. While doing the “size of Cygwin” research, I managed to stuff up my installation badly enough to need a reinstall a few times. :) http://stackoverflow.com/questions/21230657/ I’m not sure I’ve had to reinstall more often than for PC upgrades and such previously. This proposed change should also allow Windows 8+’s File History feature to back up Cygwin user files. It only backs up files that are in places normal users *should* be writing files. http://www.howtogeek.com/74623/ (File History is more or less Microsoft’s clone of Apple’s wonderful Time Machine feature. And yes, I’m aware that not everyone thinks the feature is wonderful.) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
Il 6/17/2013 8:57 AM, Eliza Tkacz RIK ha scritto: Sorry but I am not sure if I verify permissions properly. I have created a text file mytxt.txt in /tmp and then cd .. ls -l tmp/ and the output is -rw-r--r-- 1 user_name None 6 06-17 08:53 mytxt.txt try ls -l / | grep tmp an followup on the cygwin mailing lsit Regards -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
With the command ls -l / | grep tmp I have drwxrwxrwt+ 1 user_name None 0 06-17 08:53 tmp - Oryginalna wiadomość - Il 6/14/2013 4:09 PM, Eliza Tkacz RIK ha scritto: Hello, After installing the package OpenSSH I am not able to compile any fortran code using gfortran command. The compilation is terminated with: f951: fatal error: can’t open /tmp/.s for writing: No such file or directory what are the permission of /tmp ? stands for for some numbers and letters, which differ from one compilation to another. Before this last installation gfortran compilation has been warking fine. You will find attached the cygcheck.out file, where I changed only user name and some system keys. Can anyone offer advice? Thanks in advance, E.T. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- --- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
Greetings, marco atzeri! Sorry but I am not sure if I verify permissions properly. I have created a text file mytxt.txt in /tmp and then cd .. ls -l tmp/ and the output is -rw-r--r-- 1 user_name None 6 06-17 08:53 mytxt.txt try ls -l / | grep tmp I wonder, would that be different from ls -ld /tmp ? Is there any caveats under cygwin? -- WBR, Andrey Repin (anrdae...@freemail.ru) 17.06.2013, 17:35 Sorry for my terrible english...
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
Il 6/17/2013 3:36 PM, Andrey Repin ha scritto: Greetings, marco atzeri! try ls -l / | grep tmp I wonder, would that be different from ls -ld /tmp ? Is there any caveats under cygwin? Andrey Repin No, they are equivalent. I was just away from my PC and I do not remember all ls options by memory. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
On 6/14/2013 10:09 AM, Eliza Tkacz RIK wrote: Hello, After installing the package OpenSSH I am not able to compile any fortran code using gfortran command. The compilation is terminated with: f951: fatal error: can’t open /tmp/.s for writing: No such file or directory stands for for some numbers and letters, which differ from one compilation to another. Before this last installation gfortran compilation has been warking fine. You will find attached the cygcheck.out file, where I changed only user name and some system keys. Can anyone offer advice? Does uninstalling the 'openssh' package resolve the issue? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
No, it does not. E.T. - Oryginalna wiadomość - On 6/14/2013 10:09 AM, Eliza Tkacz RIK wrote: Hello, After installing the package OpenSSH I am not able to compile any fortran code using gfortran command. The compilation is terminated with: f951: fatal error: can’t open /tmp/.s for writing: No such file or directory stands for for some numbers and letters, which differ from one compilation to another. Before this last installation gfortran compilation has been warking fine. You will find attached the cygcheck.out file, where I changed only user name and some system keys. Can anyone offer advice? Does uninstalling the 'openssh' package resolve the issue? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
On 6/14/2013 10:57 AM, Eliza Tkacz RIK wrote: On 6/14/2013 10:09 AM, Eliza Tkacz RIK wrote: Hello, After installing the package OpenSSH I am not able to compile any fortran code using gfortran command. The compilation is terminated with: f951: fatal error: can’t open /tmp/.s for writing: No such file or directory stands for for some numbers and letters, which differ from one compilation to another. Before this last installation gfortran compilation has been warking fine. You will find attached the cygcheck.out file, where I changed only user name and some system keys. Can anyone offer advice? Does uninstalling the 'openssh' package resolve the issue? No, it does not. OK, you could try looking at other things that were upgraded at the same time as your 'openssh' install. Try reverting to an older version of some of these packages to see if that helps. The obvious package that everything has in common is the 'cygwin' package. You may want to start experimenting there. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory
Il 6/14/2013 4:09 PM, Eliza Tkacz RIK ha scritto: Hello, After installing the package OpenSSH I am not able to compile any fortran code using gfortran command. The compilation is terminated with: f951: fatal error: can’t open /tmp/.s for writing: No such file or directory what are the permission of /tmp ? stands for for some numbers and letters, which differ from one compilation to another. Before this last installation gfortran compilation has been warking fine. You will find attached the cygcheck.out file, where I changed only user name and some system keys. Can anyone offer advice? Thanks in advance, E.T. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
Robert Miles robertmiles at bellsouth.net writes: Hello , I had same problem . The reason was older cygwin1.dll . Try to delete all of them (also in c:\Windows\System32\ directory) , and reinstall cygwin package with setup.exe (cygwin : The Linux emulation engine) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh -X : connect /tmp/.X11-unix/X0: No such file or directory
On Fri, Apr 20, 2012, at 19:53, Jon TURNEY wrote: On 20/04/2012 11:43, Ronald Fischer wrote: My setup so far (which is working well), was to use Xming as X-Server and putty for logging into our Solaris hosts via ssh. Since I have Cygwin installed, I thought I could use its ssh equally well, so I exported the ssh key from putty to the format understood by ssh, and used the following bash command to login to the Solaris host: DISPLAY=:0.0 TERM=xterm ssh -p 22 -K -X -i MyPrivateKeyFile MyUserName@SolarisHost When I now try to start an X application, I get an error message like this connect /tmp/.X11-unix/X0: No such file or directory XIO: fatal IO error 131 (Connection reset by peer) on X server SolarisHost:239.0 after 0 requests (0 known processed) with 0 events remaining. I think I know what's going on here. The solution should be to use DISPLAY=localhost:0.0 instead, which means to connect to the X server for display 0 via TCP/IP, which the Xming X server should be listening on. Nice idea, but the result is, that I just get a different error message. Now it becomes: connect localhost port 6000: Connection refused X connection to SolarisHost:217.0 broken (explicit kill or server shutdown). From the FAQ, I see that port 6000 is the default. Could it be that I need to specify somehow a non-standard port? Ronald -- Ronald Fischer rona...@eml.cc + If a packet hits a pocket on a socket on a port, + and the bus is interrupted and the interrupt's not caught, + then the socket packet pocket has an error to report. + (cited after Peter van der Linden) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
ssh -X : connect /tmp/.X11-unix/X0: No such file or directory
My setup so far (which is working well), was to use Xming as X-Server and putty for logging into our Solaris hosts via ssh. Since I have Cygwin installed, I thought I could use its ssh equally well, so I exported the ssh key from putty to the format understood by ssh, and used the following bash command to login to the Solaris host: DISPLAY=:0.0 TERM=xterm ssh -p 22 -K -X -i MyPrivateKeyFile MyUserName@SolarisHost When I now try to start an X application, I get an error message like this connect /tmp/.X11-unix/X0: No such file or directory XIO: fatal IO error 131 (Connection reset by peer) on X server SolarisHost:239.0 after 0 requests (0 known processed) with 0 events remaining. Further investigation reveals the following: (1) I start my putty login, and find that on the remote host DISPLAY is set to (say): SolarisHost:261.0 Starting X applications works fine. (2) I start my open ssh login from Cygwin, and find that the DISPLAY variable is set to a different value, for example SolarisHost:239.0 . Starting X applications does not work. (3) In the latter shell, I export DISPLAY=SolarisHost:261.0 . Starting X applications now works. The fact that each login produces a different value for DISPLAY, is normal behaviour. Even when starting several putty sessions, each gets a different value for DISPLAY, and X apps work in all of them. It seems that by doing the ssh connection via putty, something is done which is missing from my ssh started from Cygwin. BTW, I also tried to use -Y instead of -X in my ssh invocation, but with no effect. Ronald -- Ronald Fischer rona...@eml.cc + If a packet hits a pocket on a socket on a port, + and the bus is interrupted and the interrupt's not caught, + then the socket packet pocket has an error to report. + (cited after Peter van der Linden) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: ssh -X : connect /tmp/.X11-unix/X0: No such file or directory
On 20/04/2012 11:43, Ronald Fischer wrote: My setup so far (which is working well), was to use Xming as X-Server and putty for logging into our Solaris hosts via ssh. Since I have Cygwin installed, I thought I could use its ssh equally well, so I exported the ssh key from putty to the format understood by ssh, and used the following bash command to login to the Solaris host: DISPLAY=:0.0 TERM=xterm ssh -p 22 -K -X -i MyPrivateKeyFile MyUserName@SolarisHost When I now try to start an X application, I get an error message like this connect /tmp/.X11-unix/X0: No such file or directory XIO: fatal IO error 131 (Connection reset by peer) on X server SolarisHost:239.0 after 0 requests (0 known processed) with 0 events remaining. I think I know what's going on here. cygwin ssh understands DISPLAY=:0.0 to mean to connect to the X server for display 0 via a local (UNIX domain) socket, named /tmp/.X11-unix/X0 The Xming X server, not being a cygwin application, cannot listen on that socket. The solution should be to use DISPLAY=localhost:0.0 instead, which means to connect to the X server for display 0 via TCP/IP, which the Xming X server should be listening on. See FAQ 1.6 [1] for more details. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#display-and-screen -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
Thanks Dave, it's fixed. It looks like the problem was the cygwin1.dll in C:\Windows\SYSTEM. I have no idea why that was there. (I am not the first to use this machine.) As a precaution I have also removed C:\Users\\home\apps\gcc-4.7-20120128\bin from my PATH. I had built it with --program-suffix=-4.7, but the following potentially conflicting files remain there with their names untouched: cyggfortran-3.dll cygssp-0.dll cygstdc++-6.dll Thanks again. On 24/02/2012 16:34, Dave Korn wrote: On 24/02/2012 15:36, Paul Keir wrote: echo $? returns 1 after using gcc. Right, that's helpful of it! That's clearly just a fail status but not an errno value. Anyway, I think your cygcheck reveals the problem. You have multiple cygwin1.dlls of different versions in your path at the same time. You also have a homebrew build of gcc 4.7 in your path, and it's using SJLJ exceptions rather than DW2, which means that its runtime DLLs will be incompatible with the standard system ones. Try removing the cygwin1.dll from C:\Windows\SYSTEM, and cutting C:\Users\\home\apps\gcc-4.7-20120128\bin out of your PATH, and see if that fixes it. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 27/02/2012 16:12, Paul Keir wrote: Thanks Dave, it's fixed. It looks like the problem was the cygwin1.dll in C:\Windows\SYSTEM. I have no idea why that was there. (I am not the first to use this machine.) Well, you may just find out when something else stops working - it's not unknown for people to ship custom toolchains built on Cygwin that install the DLL into the SYSTEM directory. (In which case, put the DLL you found there into the binaries dir alongside the tools involved.) As a precaution I have also removed C:\Users\\home\apps\gcc-4.7-20120128\bin from my PATH. I had built it with --program-suffix=-4.7, but the following potentially conflicting files remain there with their names untouched: cyggfortran-3.dll cygssp-0.dll cygstdc++-6.dll Although having them later in the path than the system versions in /usr/bin should in theory make that safe, mixing DW2 and SJLJ is asking for trouble to crop up somewhere down the line. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
Hello, After installing a package (libxrandr-dev I think) GCC 4.5.3 (from Exp) has a problem. Even Hello World gives me: hello.c:1:0: fatal error: can't open /tmp/ccc6IHTT.s for writing: No such file or directory compilation terminated. I have tried reinstalling GCC with no luck. Can anyone offer advice? Thanks in advance, Paul -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 24/02/2012 09:22, Paul Keir wrote: Hello, After installing a package (libxrandr-dev I think) GCC 4.5.3 (from Exp) has a problem. Even Hello World gives me: hello.c:1:0: fatal error: can't open /tmp/ccc6IHTT.s for writing: No such file or directory compilation terminated. I have tried reinstalling GCC with no luck. Can anyone offer advice? Is the drive where your /tmp dir is located full? Does it have the right permissions? Can you create the same named file manually (e.g. run a command like ls /tmp/ccc6IHTT.s)? If none of that sheds any light on it, please run cygcheck -s -v -r cygcheck.out and send that file **as an attachment only please** with your next post. Also, re-run the gcc compile command that's failing, but add the -v option to the command-line, and show us all the output it generates. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
Thanks. No, it's not full. The permissions are: drwxrwxrwt+ 1 Paul root 0 Feb 24 13:36 tmp and I can create the same file manually. The output of gcc -v hello.c is attached. I am running Windows 7 Professional - Service Pack 1. I'm afraid I can't send the output of cygcheck to the mailing list for confidentiality reasons. I could either send it to you directly, or perhaps run cygcheck in a way to generate less data. By the way I get the following errors from cygcheck, only when I redirect the output: /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'osppsvc': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5 Access is denied. On 24/02/2012 12:08, Dave Korn wrote: On 24/02/2012 09:22, Paul Keir wrote: Hello, After installing a package (libxrandr-dev I think) GCC 4.5.3 (from Exp) has a problem. Even Hello World gives me: hello.c:1:0: fatal error: can't open /tmp/ccc6IHTT.s for writing: No such file or directory compilation terminated. I have tried reinstalling GCC with no luck. Can anyone offer advice? Is the drive where your /tmp dir is located full? Does it have the right permissions? Can you create the same named file manually (e.g. run a command like ls/tmp/ccc6IHTT.s)? If none of that sheds any light on it, please run cygcheck -s -v -r cygcheck.out and send that file **as an attachment only please** with your next post. Also, re-run the gcc compile command that's failing, but add the -v option to the command-line, and show us all the output it generates. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.5.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c -mtune=generic -march=i686 -auxbase hello -version -o /tmp/ccoTtOUD.s GNU C (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/include-fixed ignoring nonexistent directory /usr/i686-pc-cygwin/include ignoring nonexistent directory /usr/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: End of search list. GNU C (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On Fri, Feb 24, 2012 at 8:52 AM, Paul Keir p...@codeplay.com wrote: Thanks. No, it's not full. The permissions are: drwxrwxrwt+ 1 Paul root 0 Feb 24 13:36 tmp and I can create the same file manually. The output of gcc -v hello.c is attached. I am running Windows 7 Professional - Service Pack 1. I'm afraid I can't send the output of cygcheck to the mailing list for confidentiality reasons. I could either send it to you directly, or perhaps run cygcheck in a way to generate less data. By the way I get the following errors from cygcheck, only when I redirect the output: You can always edit the file to blot out the sensitive data. sed -e 's.sensitive.insensitive.g' cygcheck.sensitive cygcheck.insensitive -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 24/02/2012 13:52, Paul Keir wrote: Thanks. No, it's not full. The permissions are: drwxrwxrwt+ 1 Paul root 0 Feb 24 13:36 tmp and I can create the same file manually. Oh well, always worth checking the basics first, but no real surprise! The output of gcc -v hello.c is attached. I am running Windows 7 Professional - Service Pack 1. I'm afraid I can't send the output of cygcheck to the mailing list for confidentiality reasons. I could either send it to you directly, or perhaps run cygcheck in a way to generate less data. If you're that worried I don't mind if you'd rather send it to me offlist, go ahead, but it's not like you know me well enough to trust either, so I'd suggest you redact any sensitive data (user names? passwords in environment vars?) before posting it either way. By the way I get the following errors from cygcheck, only when I redirect the output: /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'osppsvc': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5 Access is denied. That's not unexpected if you're running under a non-administrative account. There was nothing unusual in the output from gcc -v. If the cygcheck output doesn't show anything, I'll have to get you to run cc1.exe under strace. However, before we do that, there's one other thing I forgot to ask: what's the exit status after gcc fails? echo $? should show it, assuming you're using bash. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
echo $? returns 1 after using gcc. On 24/02/2012 14:57, Dave Korn wrote: On 24/02/2012 13:52, Paul Keir wrote: Thanks. No, it's not full. The permissions are: drwxrwxrwt+ 1 Paul root 0 Feb 24 13:36 tmp and I can create the same file manually. Oh well, always worth checking the basics first, but no real surprise! The output of gcc -v hello.c is attached. I am running Windows 7 Professional - Service Pack 1. I'm afraid I can't send the output of cygcheck to the mailing list for confidentiality reasons. I could either send it to you directly, or perhaps run cygcheck in a way to generate less data. If you're that worried I don't mind if you'd rather send it to me offlist, go ahead, but it's not like you know me well enough to trust either, so I'd suggest you redact any sensitive data (user names? passwords in environment vars?) before posting it either way. By the way I get the following errors from cygcheck, only when I redirect the output: /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'osppsvc': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5 Access is denied. That's not unexpected if you're running under a non-administrative account. There was nothing unusual in the output from gcc -v. If the cygcheck output doesn't show anything, I'll have to get you to run cc1.exe under strace. However, before we do that, there's one other thing I forgot to ask: what's the exit status after gcc fails? echo $? should show it, assuming you're using bash. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 24/02/2012 15:36, Paul Keir wrote: echo $? returns 1 after using gcc. Right, that's helpful of it! That's clearly just a fail status but not an errno value. Anyway, I think your cygcheck reveals the problem. You have multiple cygwin1.dlls of different versions in your path at the same time. You also have a homebrew build of gcc 4.7 in your path, and it's using SJLJ exceptions rather than DW2, which means that its runtime DLLs will be incompatible with the standard system ones. Try removing the cygwin1.dll from C:\Windows\SYSTEM, and cutting C:\Users\\home\apps\gcc-4.7-20120128\bin out of your PATH, and see if that fixes it. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 2/24/2012 3:22 AM, Paul Keir wrote: Hello, After installing a package (libxrandr-dev I think) GCC 4.5.3 (from Exp) has a problem. Even Hello World gives me: hello.c:1:0: fatal error: can't open /tmp/ccc6IHTT.s for writing: No such file or directory compilation terminated. I have tried reinstalling GCC with no luck. Can anyone offer advice? Thanks in advance, Paul Looks like time to check the read-write permissions on directory /tmp and any files inside it. Robert Miles -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
/etc/profile set $TMP to /tmp. It's insecure!
Original $TMP and $TEMP is unset in /etc/defaults/etc/skel/.bashrc version 3.9-3, which make %USERPROFILE% directory dirty. After some disscuss at http://cygwin.com/ml/cygwin/2011-03/msg00211.html, /etc/profile version 4.0-6 set $TMP and $TEMP to /tmp. Now any program start from bash, create temporary files in /tmp, or C:\cygwin\tmp. Cygwin program, which approves /tmp 's mode 1777, creates temporary files with mode 400. That's OK. Native Win32 program, which ignores /tmp 's mode 1777, creates temporary files with mode 755. These files can be read from any user. Win32 process may leak internal data, cause potential privilege escalation attack. I suggest that set $tmp (lowercase) to original $TMP, which is meaningless for cygwin programs, and is recognized for Win32 programs. Proposed settings in /etc/profile: ORIGINAL_TMP=$TMP ORIGINAL_TEMP=$TEMP unset TMP TEMP export tmp=`cygpath -w $ORIGINAL_TMP` export temp=`cygpath -w $ORIGINAL_TEMP` -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: On xkb_* in /tmp
On 07/07/2011 01:25, Angelo Graziosi wrote: Il 07/07/2011 2.12, Angelo Graziosi ha scritto: After the last upgrade to xorg-server I find in /tmp: ... 316 Jul 7 02:06 xkb_H2DcsY ... 316 Jul 7 02:06 xkb_PTGhAv Is this to be expected? Now I have seen that /tmp is filling od xkb_* files each time I login (i.e. XWin starts)... :( Thanks for reporting this. 1.10.2-1 has a change to write the keymap to a temporary file and use system() to run xkbcomp, rather than write it to a pipe and fork() xkbcomp (to avoid fork() failures preventing the X server from starting), using code that already exists for this purpose on for xming. But it seems I had failed to add the patch that xming has to ensure that these temporary files are cleaned up correctly. I'll fix this and update the X server, but in the meantime you should be able to remove these temporary files once the server has started with no ill effects :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: On xkb_* in /tmp
Il 07/07/2011 14.51, Jon TURNEY ha scritto: I'll fix this and update the X server, but in the meantime you should be able to remove these temporary files once the server has started with no ill effects :-) Thanks a lot! Ciao, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
On xkb_* in /tmp
After the last upgrade to xorg-server I find in /tmp: ...316 Jul 7 02:06 xkb_H2DcsY ...316 Jul 7 02:06 xkb_PTGhAv Is this to be expected? Ciao, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: On xkb_* in /tmp
Il 07/07/2011 2.12, Angelo Graziosi ha scritto: After the last upgrade to xorg-server I find in /tmp: ... 316 Jul 7 02:06 xkb_H2DcsY ... 316 Jul 7 02:06 xkb_PTGhAv Is this to be expected? Now I have seen that /tmp is filling od xkb_* files each time I login (i.e. XWin starts)... :( Ciao, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: TMP and TEMP get redefined, but I need the original values
On 6/12/2011 7:55 PM, Roland Bluethgen wrote: Looking for the cause I found out that the Cygwin maintainers chose to redefine the TEMP and TMP environment variables in /etc/profile However, now I'm unable to find out the original TEMP setting from a script. Windows stores the environment variables in the registry, under `HKEY_CURRENT_USER\Environment' and `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment'. You can access these through /proc/registry in cygwin. For an example see the PRINTER setting in /etc/profile. szgyg -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: TMP and TEMP get redefined, but I need the original values
szgyg wrote: Windows stores the environment variables in the registry, under `HKEY_CURRENT_USER\Environment' and `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment'. You can access these through /proc/registry in cygwin. For an example see the PRINTER setting in /etc/profile. That is an excellent note. Documentation can be found at http://www.cygwin.com/cygwin-ug-net/using-specialnames.html. The regtool might be also useful in this regard. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: TMP and TEMP get redefined, but I need the original values
* Roland Bluethgen (Sun, 12 Jun 2011 23:01:12 +0200) Thorsten Kampe wrote: If you want Linux TMP and Windows TMP point to the same directory then mount it in fstab or use $USERPROFILE/AppData/Local/Temp. I shortened the story a bit, it's really more complicated. The TMP definition in my case is user-crafted, not the default value which is normally set up when a user is created in the Windows system. TMP in Cygwin is user-crafted? TMP in Windows? TMP in your script? Also, this approach would defeat the intended purpose of the redefinition of TMP (avoiding permissions screwup). Or am I missing something here? If you're the only Cygwin user on your machine, this is a reasonable way. Otherwise not. Thorsten -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: TMP and TEMP get redefined, but I need the original values
Thorsten Kampe wrote: * Roland Bluethgen (Sun, 12 Jun 2011 23:01:12 +0200) TMP in Cygwin is user-crafted? TMP in Windows? TMP in your script? TMP in Windows. Also, this approach would defeat the intended purpose of the redefinition of TMP (avoiding permissions screwup). Or am I missing something here? If you're the only Cygwin user on your machine, this is a reasonable way. Otherwise not. You mean, the permissions problem only surfaces on machines, where multiple users use the same cygwin install? Ok, I'll consider that. For now I resorted to copying the TEMP value to WINDOWS_TEMP on the native Windows side already, and then refer to that backup from the script in question. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
