Re: Strange cygpath behavior.
On 6/23/2011 10:12 AM, Corinna Vinschen wrote: I don't know what the difference in your settings is, though. Something with readline, maybe. Despite the APPEARANCE (*) of invoking cygpath from within a cygwin shell, it seems the OP is actually invoking cygpath directly from a regular cmd.exe console: On my machine, from cmd.exe: C:\cygwin\bincygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile On my machine, from bash.exe: $ cygpath -u \\DAEMON1\anrdaemon\.profile /c/DAEMON1anrdaemon.profile (*) [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile ^^ oh, look, a unix-style command prompt, aka $PS1... -- Chuck
Re: Strange cygpath behavior.
Sorry, wrong list. Redirected. On 6/23/2011 12:44 PM, Charles Wilson wrote: On 6/23/2011 10:12 AM, Corinna Vinschen wrote: I don't know what the difference in your settings is, though. Something with readline, maybe. Despite the APPEARANCE (*) of invoking cygpath from within a cygwin shell, it seems the OP is actually invoking cygpath directly from a regular cmd.exe console: On my machine, from cmd.exe: C:\cygwin\bincygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile On my machine, from bash.exe: $ cygpath -u \\DAEMON1\anrdaemon\.profile /c/DAEMON1anrdaemon.profile (*) [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile ^^ oh, look, a unix-style command prompt, aka $PS1...
Re: I lose characters because keycode of Fn is same than DEL
On 10/06/2011 10:33, Paul Maier wrote: on a a IBM Lenovo Laptop T60 there is a Fn key to adjust the screen brightness and such. That Fn key has the same keycode than the DEL key. Therefore I can't change the Fn key with xmodmap (because I would change the DEL key the same way.) When I adjust the screen brightness, I lose characters in the editor. Unfortunately the Fn key REPEATS firing delete while the key is pressed. And several times I didn't notice the loss before saving and leaving the editor. Here is the output of xev when I press the Fn key: (Pressing the DEL key would yield the very same output.) KeyPress event, serial 20, synthetic NO, window 0xa1, root 0x101, subw 0xa2, time 42594031, (35,42), root:(259,282), state 0x0, keycode 107 (keysym 0x, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) 7f XFilterEvent returns: False What can we do? Thanks for the bug report. I think this is a bug in the way XWin translates Windows keystrokes into X keycodes. Can you run the X server with the extra option '-logverbose 3' and report what is written to /var/log/xwin/XWin.0.log when you press the Fn key. -- 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/
[PATCH] Prevent restart of crashing non-Cygwin exe
If a non-Cygwin .exe started from a Cygwin shell window segfaults,
Cygwin restarts the .exe 5 times.
Testcase:
$ cat crash.c
#include stdio.h
int main()
{
printf(Hello, ); fflush(stdout);
*(char *)0 = 42;
printf(World\n);
return 0;
}
$ gcc -o crash-c crash.c
$ ./crash-c
Hello, Segmentation fault (core dumped)
$ i686-w64-mingw32-gcc -o crash-w crash.c
$ ./crash-w
Hello, Hello, Hello, Hello, Hello, Hello,
(The repeated outputs are not be visible on 1.7.9-1 when shell runs in a
Windows console without CYGWIN=tty)
The problem is that Cygwin retries CreateProcess() if process aborts
with an unknown 0xc exit code also for non-Cygwin programs. The
attached patch fixes this.
Christian
2011-06-23 Christian Franke fra...@computer.org
* sigproc.cc (child_info::sync): Add exit_code to debug
message.
(child_info::proc_retry): Don't retry on unknown exit_code
from non-cygwin programs.
diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
index 2f42db2..1e57876 100644
--- a/winsup/cygwin/sigproc.cc
+++ b/winsup/cygwin/sigproc.cc
@@ -883,7 +883,8 @@ child_info::sync (pid_t pid, HANDLE hProcess, DWORD howlong)
hProcess = NULL;
}
}
- sigproc_printf (pid %u, WFMO returned %d, res %d, pid, x, res);
+ sigproc_printf (pid %u, WFMO returned %d, exit_code 0x%x, res %d,
+ pid, x, exit_code, res);
}
return res;
}
@@ -915,11 +916,11 @@ child_info::proc_retry (HANDLE h)
case EXITCODE_FORK_FAILED: /* windows prevented us from forking */
break;
-/* Count down non-recognized exit codes more quickly since they aren't
- due to known conditions. */
default:
- if (!iscygwin () (exit_code 0x) != 0xc000)
+ if (!iscygwin ())
break;
+ /* Count down non-recognized exit codes more quickly since they aren't
+ due to known conditions. */
if ((retry -= 2) 0)
retry = 0;
else
Re: Strange cygpath behavior.
Greetings, Peter Rosin! I'm facing an unacceptable cygpath behavior related to the network shares. Unacceptable? Exactly. Perhaps your quoting skills and expectations fall into that category... The testcase is: [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile I think you mean cygpath -u DAEMON1\\anrdaemon\\.profile No, I did mean what I wrote. [\\DAEMON1\anrdaemon]$cygpath -m \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile I think you mean cygpath -m //DAEMON1/anrdaemon/.profile No. (-m expects posix path arguments) How come? Switch only defining the result, not the source data. [\\DAEMON1\anrdaemon]$cygpath -lm \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile I think you mean cygpath -lm //DAEMON1/anrdaemon/.profile You think wrong. [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile /DAEMON1/anrdaemon/.profile I think you mean cygpath -u DAEMON1\\anrdaemon\\.profile Again, no. [\\DAEMON1\anrdaemon]$cygpath -m \\DAEMON1\anrdaemon\.profile ///DAEMON1/anrdaemon/.profile I think you mean cygpath -m //DAEMON1/anrdaemon/.profile No, yet again. [\\DAEMON1\anrdaemon]$cygpath -lm \\DAEMON1\anrdaemon\.profile ///DAEMON1/anrdaemon/.profile I think you mean cygpath -lm //DAEMON1/anrdaemon/.profile No, for the last time. Only unquoted path producing usable results, but it's not realistically imaginable I would let it run this way. One day I will sure meet a file with ] in it's name, and the surrounding environment will break. Or, even simpler, I'll hit a filename with spaces... This issue arising in different places of cygwin (originally I got nailed by it when trying to run diff across my now-network profile folder). cygpath is just a closest example I could reach for this message. Glad you quoted it, strange that you didn't read it. -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.06.2011, 16:49 Sorry for my terrible english... -- 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: Strange cygpath behavior.
On Jun 21 09:23, Andrey Repin wrote: Greetings, All! I'm facing an unacceptable cygpath behavior related to the network shares. The testcase is: Here's what happens on my machine: [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile /cygdrive/c/DAEMON1anrdaemon.profile [\\DAEMON1\anrdaemon]$cygpath -m \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile C:/DAEMON1anrdaemon.profile [\\DAEMON1\anrdaemon]$cygpath -lm \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile C:/DAEMON1anrdaemon.profile [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile /DAEMON1/anrdaemon/.profile /cygdrive/c/DAEMON1/anrdaemon/.profile [\\DAEMON1\anrdaemon]$cygpath -m \\DAEMON1\anrdaemon\.profile ///DAEMON1/anrdaemon/.profile C:/DAEMON1/anrdaemon/.profile [\\DAEMON1\anrdaemon]$cygpath -lm \\DAEMON1\anrdaemon\.profile ///DAEMON1/anrdaemon/.profile C:/DAEMON1/anrdaemon/.profile Alternatively: $ cygpath -u '\\DAEMON1\anrdaemon\.profile' //DAEMON1/anrdaemon/.profile $ cygpath -m '\\DAEMON1\anrdaemon\.profile' //DAEMON1/anrdaemon/.profile $ cygpath -lm '\\DAEMON1\anrdaemon\.profile' //DAEMON1/anrdaemon/.profile Only unquoted path producing usable results, but it's not realistically imaginable I would let it run this way. There's something weird in your bash settings. Usually bash will fold the backslashes before using the string as argument to the child process. See the behaviour with echo: $ echo \a a $ echo \\a \a $ echo \a \a $ echo \\a \a $ echo '\a' \a $ echo '\\a' \\a So what cygpath gets as argument in your first example is usually \DAEMON1anrdaemon.profile I don't know what the difference in your settings is, though. Something with readline, maybe. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Strange cygpath behavior.
On 6/23/2011 2:52 PM, Andrey Repin wrote: Greetings, Peter Rosin! I'm facing an unacceptable cygpath behavior related to the network shares. Unacceptable? Exactly. Unacceptable seems a moral judgement, for this reason I guess Peter is perplexed. Perhaps your quoting skills and expectations fall into that category... The testcase is: [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile I think you mean cygpath -u DAEMON1\\anrdaemon\\.profile No, I did mean what I wrote. What about a more clear explanation of what do you expect to obtain ? I have problem to understand your problem, while Peter answer seems more obvious (to me). Problem reports: http://cygwin.com/problems.html In general the \ is used as escape character so unquoted it just preserves the next character \\DAEMON1\anrdaemon\.profile is equivalent to \DAEMON1anrdaemon.profile Glad you quoted it, strange that you didn't read it. -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.06.2011,16:49 Sorry for my terrible english... better than my Russian 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: Strange cygpath behavior.
Greetings, Marco atzeri!
I'm facing an unacceptable cygpath behavior related to the network shares.
Unacceptable?
Exactly.
Unacceptable seems a moral judgement, for this reason
I guess Peter is perplexed.
Perhaps your quoting skills and expectations fall
into that category...
The testcase is:
[\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile
//DAEMON1/anrdaemon/.profile
I think you mean cygpath -u DAEMON1\\anrdaemon\\.profile
No, I did mean what I wrote.
What about a more clear explanation of what do you expect
to obtain ?
Me? I expect to be able to use Cygwin utilities in Windows environment.
As supposed to... to my best knowledge.
I have problem to understand your problem,
while Peter answer seems more obvious (to me).
Problem is that path detection/conversion does not work for network paths.
Problem reports: http://cygwin.com/problems.html
In general the \ is used as escape character so unquoted
it just preserves the next character
\\DAEMON1\anrdaemon\.profile
is equivalent to
\DAEMON1anrdaemon.profile
Try it yourself, as well as what Peter tried to suggest (or correct me).
Neither is working straight.
Just for example:
$ cygpath -u DAEMON1\\anrdaemon\\.profile
/c/DAEMON1/anrdaemon/.profile
Or, before we get lost, try to make this simple and widely used construction
work straight:
#! /bin/sh
XXX=${XXX:=$(readlink -fn $0)}
XXX=$(dirname $XXX)
ls -l $XXX
Cygwin, to my best understanding, is supposed to transparently accept native
Windows paths.
And, say,
diff %USERPROFILE%\.profile someotherprofile\.profile
works... as long as it's a local path (including mapped drives).
Network paths break instantly.
--
WBR,
Andrey Repin (anrdae...@freemail.ru) 23.06.2011, 18:47
Sorry for my terrible english...
--
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: Strange cygpath behavior.
* Andrey Repin (Thu, 23 Jun 2011 19:05:34 +0400) Try it yourself, as well as what Peter tried to suggest (or correct me). Neither is working straight. Just for example: $ cygpath -u DAEMON1\\anrdaemon\\.profile /c/DAEMON1/anrdaemon/.profile $ cygpath -u DAEMON1\\anrdaemon\\.profile //DAEMON1/anrdaemon/.profile Or, before we get lost [...] Before /you/ get lost in your own ramblings: read Corinna's response. In case she's too elaborate, the simple version is: /you/ have a problem and the problem is entirely on /your/ side. 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: Strange cygpath behavior.
On 6/23/2011 5:05 PM, Andrey Repin wrote: Greetings, Marco atzeri! Cygwin, to my best understanding, is supposed to transparently accept native Windows paths. No, cygwin expects to receive POSIX/Unix paths $ cygpath -h [cut] -u, --unix(default) print Unix form of NAMEs (/cygdrive/c/winnt) so cygpath -u expects to receive a Windows path and convert it in a unix one. From your example: cygpath -u DAEMON1\\anrdaemon\\.profile /c/DAEMON1/anrdaemon/.profile the argument is an escaped windows network path and the outcome is the Unix equivalent As Corinna explained: $ echo DAEMON1\\anrdaemon\\.profile \\DAEMON1\anrdaemon\.profile By the way resetting cygdrive is not a good idea, it is better to obtain /cygdrive/c/DAEMON1/anrdaemon/.profile -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.06.2011,18:47 Sorry for my terrible english... 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: Strange cygpath behavior.
Greetings, Corinna Vinschen! There's something weird in your bash settings. My apology. I forgot to mention, it wasn't executed from bash. I've tried it from 4NT command prompt and from native Windows CMD prompt. Under both, cygpath exhibited the same behavior, as well as other programs (diff, readlink (inside shell script, launched through env.exe from windows association** - as shown in mid:1144668147.20110623190...@mtu-net.ru ) and so on). Usually bash will fold the backslashes before using the string as argument to the child process. That's true for when you launch scripts from bash'ed console. But when you just launch script/program from an unknown environment, that's not always work straight. As I said earlier, diff works as long as both file arguments are local (X:\path\file), but break apart on network names, be it Windows (\\...)or Unix (//...) style. Only way I've found so far is to attempt a nontrivial and very leveled fool-checking, but that way I'm shooting myself into the leg, as such a proof-reading reduce my ability to supply additional arguments to, i.e., diff. I don't know what the difference in your settings is, though. Something with readline, maybe. Seeing as even cygpath exhibiting such strange behavior, I suspect something in the base path translation logic. P.S. I drastically reduced the quote, as it seems that my reply isn't directly related to it's text, and leaving it in place would've highly reduced the message readability, but I still feeling sorry for such a truncation. So, there's my apology again. P.P.S. **That association. $ assoc .sh .sh=unixshell.script $ ftype unixshell.script unixshell.script=C:/Programs/Cygwin/bin/env.exe %1 %* -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.06.2011, 19:54 Sorry for my terrible english... -- 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: Strange cygpath behavior.
Sorry, wrong list. Redirected. On 6/23/2011 12:44 PM, Charles Wilson wrote: On 6/23/2011 10:12 AM, Corinna Vinschen wrote: I don't know what the difference in your settings is, though. Something with readline, maybe. Despite the APPEARANCE (*) of invoking cygpath from within a cygwin shell, it seems the OP is actually invoking cygpath directly from a regular cmd.exe console: On my machine, from cmd.exe: C:\cygwin\bincygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile On my machine, from bash.exe: $ cygpath -u \\DAEMON1\anrdaemon\.profile /c/DAEMON1anrdaemon.profile (*) [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile ^^ oh, look, a unix-style command prompt, aka $PS1... -- 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: Strange cygpath behavior.
Greetings, Marco atzeri! On 6/23/2011 5:05 PM, Andrey Repin wrote: Greetings, Marco atzeri! Cygwin, to my best understanding, is supposed to transparently accept native Windows paths. No, cygwin expects to receive POSIX/Unix paths $ cygpath -h [cut] -u, --unix(default) print Unix form of NAMEs (/cygdrive/c/winnt) so cygpath -u expects to receive a Windows path and convert it in a unix one. That's your assumption. Which is not necessarily true. (Unless you're author of cygpath, in which case you have full authority to tell me what it is supposed to be.) Man page and reference card both do not specify the exact argument format, only the intended result format. And just to be clear, windows in the core don't see a difference between the path in format of C:/whatever/... or C:\whatever\ This behavior is very, very old. Even older than Windows itself, if you know, what INT 21h means. From your example: cygpath -u DAEMON1\\anrdaemon\\.profile /c/DAEMON1/anrdaemon/.profile the argument is an escaped windows network path and the outcome is the Unix equivalent Not true for the outcome part. stdout:cygpath -w /c/DAEMON1/anrdaemon/.profile C:\DAEMON1\anrdaemon\.profile Which is far from original network path. As Corinna explained: $ echo DAEMON1\\anrdaemon\\.profile \\DAEMON1\anrdaemon\.profile I already said that I'm sorry, that I forgot to mention what seems to be critical bit of information. By the way resetting cygdrive is not a good idea, it is better to obtain To tell you, that was actually a good idea for me. I don't have an eternity to type /cygwhatever every time I want to address another drive. So the idea to map cygdrive to / was actually very handy, thanks to this mailing list helping to finish and polish it. -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.06.2011, 20:58 Sorry for my terrible english... -- 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: Strange cygpath behavior.
Greetings, Charles Wilson! I don't know what the difference in your settings is, though. Something with readline, maybe. Despite the APPEARANCE (*) of invoking cygpath from within a cygwin shell, it seems the OP is actually invoking cygpath directly from a regular cmd.exe console: On my machine, from cmd.exe: C:\cygwin\bincygpath -u \\DAEMON1\anrdaemon\.profile //DAEMON1/anrdaemon/.profile On my machine, from bash.exe: $ cygpath -u \\DAEMON1\anrdaemon\.profile /c/DAEMON1anrdaemon.profile (*) [\\DAEMON1\anrdaemon]$cygpath -u \\DAEMON1\anrdaemon\.profile ^^ oh, look, a unix-style command prompt, aka $PS1... Eh, yep . The default Windows/DOS prompt confusing me, it had a completely different meaning back in the days, so I always change it to reduce my nerve stress. -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.06.2011, 22:25 Sorry for my terrible english... -- 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
Version skew: Emacs 23.3-{1,2} vs cygwin1.dll/silent failure of emacs
There seems to be a problem with using the latest emacs and latest
cygwin dll together.
I updated my cygwin release yesterday in hopes of fixing the broken
openssh/git problem (which wasn't fixed!). However, in the process I
lost emacs.
Behavior: all versions of emacs currently available with the cygwin
installer (i.e. 23.3-{1,2}) fail silently.
Under slightly more investigation, it turns out that they were failing
because of a missing routine: _feinitialise().
A little investigation suggests to me that perhaps this routine got
added to the 1.7.8 release and removed from the 1.7.9 release. So, I
backed out to 1.7.8 dll and emacs worked again. I suspect that emacs
needs to be recompiled to work with 1.7.9.
My uninformed $0.02.
--KUBI--
--
Professor John Kubiatowicz
673 Soda Hall
Berkeley, CA 94720-1776
--
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: Strange cygpath behavior.
* Andrey Repin (Thu, 23 Jun 2011 22:06:05 +0400) To tell you, that was actually a good idea for me. I don't have an eternity to type /cygwhatever every time I want to address another drive. Ever heard of tab completion? So the idea to map cygdrive to / was actually very handy, thanks to this mailing list helping to finish and polish it. Right. So instead of a clean Cygwin root layout like... |---bin |---cygdrive | |---c | |---d | |---e | |---f | `---z |---dev |---etc |---home |---lib |---proc |---sbin |---tmp |---usr `---var ...you will now have something like... |---bin |---c |---d |---dev |---e |---etc |---f |---home |---lib |---proc |---sbin |---tmp |---usr |---var `---z 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: Version skew: Emacs 23.3-{1,2} vs cygwin1.dll/silent failure of emacs
On 6/23/2011 2:46 PM, John Kubiatowicz wrote:
There seems to be a problem with using the latest emacs and latest
cygwin dll together.
I updated my cygwin release yesterday in hopes of fixing the broken
openssh/git problem (which wasn't fixed!). However, in the process I
lost emacs.
Behavior: all versions of emacs currently available with the cygwin
installer (i.e. 23.3-{1,2}) fail silently.
Under slightly more investigation, it turns out that they were failing
because of a missing routine: _feinitialise().
A little investigation suggests to me that perhaps this routine got
added to the 1.7.8 release and removed from the 1.7.9 release. So, I
backed out to 1.7.8 dll and emacs worked again. I suspect that emacs
needs to be recompiled to work with 1.7.9.
emacs-23.3-2 works fine for me with cygwin-1.7.9.
A program failing silently is often a sign of a missing DLL. Maybe one
of the dependencies of emacs didn't get installed. Try 'cygcheck
/usr/bin/emacs' and see if it reports anything missing.
Ken
--
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
Installing cygwin on Windows 7 prompts for Admin credentials
Hi, I would like to let one of my users install cygwin as a normal (non-admin) account. However, when they run setup.exe, they get a UAC prompt Do you want to allow the following program from an unknown publisher to make changes to your computer? To continue, type an administrator password, and then click Yes. I'd like to let them install it, but obviously I don't want to give them admin privs. What else can I do to workaround this? -- Robert Jacobson -- 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: Installing cygwin on Windows 7 prompts for Admin credentials
I have tried to install Cygwin for Windows 7 but it failed to finish installation and stalls at 99% .No idea why but never was asked on allowing it to make changes to the computer. i am also using plain text format and hope this message go through for god sake! On Thu, Jun 23, 2011 at 3:52 PM, Robert Jacobson q7zfcr...@sneakemail.com wrote: Hi, I would like to let one of my users install cygwin as a normal (non-admin) account. However, when they run setup.exe, they get a UAC prompt Do you want to allow the following program from an unknown publisher to make changes to your computer? To continue, type an administrator password, and then click Yes. I'd like to let them install it, but obviously I don't want to give them admin privs. What else can I do to workaround this? -- Robert Jacobson -- 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: Version skew: Emacs 23.3-{1,2} vs cygwin1.dll/silent failure of emacs
On 6/23/2011 12:24 PM, Ken Brown wrote: emacs-23.3-2 works fine for me with cygwin-1.7.9. A program failing silently is often a sign of a missing DLL. Maybe one of the dependencies of emacs didn't get installed. Try 'cygcheck /usr/bin/emacs' and see if it reports anything missing. Ken But the complaint that I was getting was of the missing _feinitialise(). And, the only thing I did to fix it was install cygwin-1.7.8 dll... I'm not near that machine now, but I will try what you suggest again later. Perhaps it was 23.3-1 that had the problem, not 23.3-2. Since both emacs' were failing silently, I assumed they both had the problem. Note that one of the post-install scripts failed with 1.7.9 as well (not with 1.7.8), so not really sure what is happening. More info later, --KUBI-- -- Professor John Kubiatowicz 673 Soda Hall Berkeley, CA 94720-1776 -- 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: Version skew: Emacs 23.3-{1,2} vs cygwin1.dll/silent failure of emacs
On 6/23/2011 2:24 PM, John Kubiatowicz wrote: On 6/23/2011 12:24 PM, Ken Brown wrote: emacs-23.3-2 works fine for me with cygwin-1.7.9. A program failing silently is often a sign of a missing DLL. Maybe one of the dependencies of emacs didn't get installed. Try 'cygcheck /usr/bin/emacs' and see if it reports anything missing. Ken But the complaint that I was getting was of the missing _feinitialise(). And, the only thing I did to fix it was install cygwin-1.7.8 dll... I'm not near that machine now, but I will try what you suggest again later. Perhaps it was 23.3-1 that had the problem, not 23.3-2. Since both emacs' were failing silently, I assumed they both had the problem. Note that one of the post-install scripts failed with 1.7.9 as well (not with 1.7.8), so not really sure what is happening. More info later, --KUBI-- Ok. Now I'm thoroughly confused. All I did was install 1.7.9 cygwin dll again. Emacs works. Must have been a different dll that wasn't being installed. So, if this problem recurs, I'll run cygcheck. Sorry for the apparent false alarm. Very weird. The only thing that I can think of is that I may have upgraded from 1.7.8 to 1.7.9 (i.e. upgraded past 1.7.8). So, perhaps I gained some dll that I was otherwise missing by downgrading to exactly 1.7.8 then back up to 1.7.9? --KUBI-- -- Professor John Kubiatowicz 673 Soda Hall Berkeley, CA 94720-1776 -- 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
Error message: setup.exe is not a valid Win32 application
I downloaded http://cygwin.com/setup.exe several times, but it won't run. My OS is Windows XP, 32 bit. The error I keep getting is setup.exe is not a valid Win32 application. Does the web site have the wrong file? Alex -- 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: Error message: setup.exe is not a valid Win32 application
Greetings, lx_cyg...@alexnews3.fastmail.fm! I downloaded http://cygwin.com/setup.exe several times, but it won't run. My OS is Windows XP, 32 bit. The error I keep getting is setup.exe is not a valid Win32 application. Does the web site have the wrong file? If you're using IE to download it, try clearing your browser file cache. (Also related to other browsers, but to a much lesser degree.) Also make sure no antivirus interfere with your download in unpredicted way. In short, your downloaded file is corrupt. -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.06.2011, 4:08 Sorry for my terrible english... -- 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: Strange cygpath behavior.
Greetings, Thorsten Kampe! To tell you, that was actually a good idea for me. I don't have an eternity to type /cygwhatever every time I want to address another drive. Ever heard of tab completion? In editor? ... There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. Hamlet. Act I, Scene V So the idea to map cygdrive to / was actually very handy, thanks to this mailing list helping to finish and polish it. Right. So instead of a clean Cygwin root layout like... It's clean enough for me. Thanks for caring, though. -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.06.2011, 3:54 Sorry for my terrible english... -- 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
