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
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&#
*Bogotá, Sunday April 2nd, 2023*
*REF: 'tac' trying to use "/tmp"; Error: not found*
*___*
*| 'tac' utility dies with a not found "/tmp" error. |*
*¯
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.11
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:\
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
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 a
-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 v
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 fi
fault-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
> >>>
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 t
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
>>>>>>>>&
>>>>>>>> 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)
t; 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'
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"));
p
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 (&
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
>>>>>> 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
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
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
> >>> 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 ma
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
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
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
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
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
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
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
> | 1688
ODA 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 ine
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 dis
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 o
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 th
..]
> 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
> cygwi
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
> S
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&#
2015-04-11 2:35 GMT+02:00 LRN :
> 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 ref
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 yo
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 th
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 serv
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
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 ch
On Nov 15, 2014, at 10:55 AM, Lee 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 id
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 no
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/directori
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 ins
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
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.
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 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
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 wo
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 Cygw
out /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
On Nov 13 15:20, Warren Young wrote:
> On Nov 13, 2014, at 3:09 PM, Corinna Vinschen
> 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 i
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
On Nov 13, 2014, at 3:09 PM, Corinna Vinschen 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(Warre
On Nov 13 14:39, Warren Young wrote:
> On Nov 13, 2014, at 2:30 PM, Corinna Vinschen
> 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:(
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
> > 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 ye
On Nov 13, 2014, at 2:30 PM, Corinna Vinschen 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 d
sn’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
On Nov 13 14:09, 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
> >> A
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?
tab 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/
On Nov 12 17:19, Warren Young wrote:
> On Nov 12, 2014, at 3:43 PM, Andrew DeFaria
> 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 an
On Nov 12, 2014, at 3:43 PM, Andrew DeFaria 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
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
ns 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:
>>
>>
>&g
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
, /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
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
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 &qu
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
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 us
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
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
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
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 e
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
Robert Miles 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: htt
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 f
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 --pr
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
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 sam
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 b
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 he
On Fri, Feb 24, 2012 at 8:52 AM, 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.
>
> The output of gcc -v hello.c is attached. I am running Windows 7
> Profes
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
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 director
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
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
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 /
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 enviro
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
* 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
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 whi
eBSD
does it this way, it's rather complicated procedure.
Therefore I think that the TMP/TEMP setting should go
into /etc/profile.d/temp.sh or some such, so that it can be removed or
modified without touching /etc/profile.
I'm not sure if it's so easy. The profile.d inclusion
* Roland Bluethgen (Sun, 12 Jun 2011 19:55:56 +0200)
> I don't update my Cygwin installation regularly, but recently I did,
and
> then a script of mine stopped working.
>
> Looking for the cause I found out that the Cygwin maintainers chose to
> redefine the TEMP and TMP e
the cause I found out that the Cygwin maintainers chose to
>> redefine the TEMP and TMP environment variables in /etc/profile like this:
>>
>> unset TMP TEMP
>> TMP="/tmp"
>> TEMP="/tmp"
>>
>> http://cygwin.com/ml/cygwin/2011-03/msg0021
On 6/12/2011 1:55 PM, Roland Bluethgen wrote:
Hey folks!
I don't update my Cygwin installation regularly, but recently I did, and
then a script of mine stopped working.
Looking for the cause I found out that the Cygwin maintainers chose to
redefine the TEMP and TMP environment variabl
Hey folks!
I don't update my Cygwin installation regularly, but recently I did, and
then a script of mine stopped working.
Looking for the cause I found out that the Cygwin maintainers chose to
redefine the TEMP and TMP environment variables in /etc/profile like this:
unset TMP TEM
IMHO.
>
> I've been thinking about this, and I'd rather keep TMP/TEMP set to
> /tmp in /etc/profile. This is mainly because the code that sets HOME could
> need TMP to be already set under some circumstances, and the function
> that sources the scripts under /etc/profile.d is
mplish. In what situation would this have to be
> > >changed on a per-system level? Why isn't it sufficient that the
> > >user can change it in the own user profiles?
> > For example if cygwin is still installed on a FAT drive (I know ...)
> > it may be useful (f
1 - 100 of 290 matches
Mail list logo
