genini: comments
setup.html says (emphasis mine):
Lines that *begin* with '#' are considered to be comments and are
ignored by the setup.ini generator.
Some of my sdesc/ldesc include a '#' not in the context of a comment
(e.g. C#), and this was causing the rest of the field to be chomp()ed,
mangling the resulting setup.ini.
Patch attached.
Yaakov
2010-06-08 Yaakov Selkowitz yselkow...@users.sourceforge.net
* genini (parse): comments are only allowed at the beginning of a line.
Index: genini
===
RCS file: /cvs/cygwin-apps/genini/genini,v
retrieving revision 1.12
diff -u -r1.12 genini
--- genini 14 Mar 2010 18:31:30 - 1.12
+++ genini 9 Jun 2010 04:09:13 -
@@ -114,7 +114,7 @@
open(\*F, '', $f) or die $0: couldn't open $f - $!\n;
while (F) {
chomp;
- s/#.*$//o;
+ s/^#.*$//o;
s/^\s+//o;
s/(\S)\s+$/$1/o;
length or next;
Re: genini: comments
On Tue, Jun 08, 2010 at 11:32:39PM -0500, Yaakov (Cygwin/X) wrote: setup.html says (emphasis mine): Lines that *begin* with '#' are considered to be comments and are ignored by the setup.ini generator. Some of my sdesc/ldesc include a '#' not in the context of a comment (e.g. C#), and this was causing the rest of the field to be chomp()ed, mangling the resulting setup.ini. Patch attached. That's not right. The intent is to provide comments like: foo: bar #comment cgf
Re: genini: comments
On Wed, 2010-06-09 at 00:38 -0400, Christopher Faylor wrote: That's not right. The intent is to provide comments like: foo: bar #comment Ah, well according to the website, mid-line comments are not allowed. But if the website is wrong and they are supposed to be allowed, then those within quotes (for sdesc/ldesc fields) should be ignored. Yaakov
Re: frequently getting a STATUS_ACCESS_VIOLATION exception under win7
Yuval Emek yuval.emek at gmail.com writes: A very annoying situation: I'm getting a STATUS_ACCESS_VIOLATION exception in about 2 out of 3 operations performed under cygwin/x. An operation in this context can be starting an x application (e.g., xterm) or running some command from within emacs (e.g., diff or latex). In attempt to isolate the problem, I reinstalled cygwin from scratch using the default settings of setup.exe + xorg-server, xinit, xorg-docs, and X-start-menu-icons. Next, I open a cygwin bash window and then invoke startxwin.exe . The x-server is invoked but an xterm window does not open and the following message appears: ***message begins*** 4 [main] xterm 7156 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1449 [main] xterm 7156 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 4 [main] xterm 7996 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1356 [main] xterm 7996 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 4 [main] xterm 5268 exception::handle: Exception: STATUS_ACCESS_VIOLATION 647 [main] xterm 5268 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 5 [main] xterm 4316 exception::handle: Exception: STATUS_ACCESS_VIOLATION 739 [main] xterm 4316 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 2752 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1123 [main] xterm 2752 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 5 [main] xterm 3220 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1260 [main] xterm 3220 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 6 [main] xterm 6752 fork: child -1 - died waiting for longjmp before initi alization, retry 0, exit code 0x600, errno 11 xterm: Error 29, errno 11: Resource temporarily unavailable Reason: spawn: fork() failed ***message ends*** The content of the resulting xterm.exe.stackdump file: ***content begins*** Exception: STATUS_ACCESS_VIOLATION at eip=610202F7 eax=00C500F8 ebx=612294A4 ecx=755F783F edx=002620F0 esi= edi=0022FA14 ebp=61020A10 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 3220, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args End of stack trace ***content ends*** This phenomenon (or a similar one where I'm getting only 1 or two lines of the exception and xterm does open) is very common: it happens in about 2 out of 3 startxwin.exe invocation attempts. The same thing happens when I'm trying to open a new xterm window from an existing one. I'm using Windows 7 (32 bits). This is probably a relevant info as my old laptop (with Windows XP) works fine (once again with a fresh installation of cygwin + cygwin/x). I'm somewhat surprised that this problem was not reported before since I know that my office mate suffers from it as well (she is also using Windows 7 32 bits). I've already tried to discuss this problem in the cygwin mailing list (see http://cygwin.com/ml/cygwin/2010-04/msg00740.html) without a positive resolution. Thinking about it some more, I now understand that this problem occurs only under x, so I hope that this is the right mailing list. Any suggestions? The output of cygcheck -s -v -r and the content of /var/log/XWin.0.log are attached. Attachment (XWin.0.log): application/octet-stream, 4224 bytes Attachment (xterm.exe.stackdump): application/octet-stream, 321 bytes -- 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/ I got the same problem on windows 7 64 bit home premium edition with Cygwin 1.7.5 And it is no problem on windows XP with Cygwin 1.7.5 $ 2 [main] xterm 4552 exception::handle: Exception: STATUS_ACCESS_VIOLATIO N 1665 [main] xterm 4552 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 5260 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1220 [main] xterm 5260 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 2324 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1149 [main] xterm 2324 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 4196 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1154 [main] xterm 4196 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 5112 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1696 [main] xterm 5112 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 2484 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1660 [main] xterm 2484 open_stackdumpfile: Dumping stack trace to xterm.exe.s tackdump 2 [main] xterm 536 fork:
Re: frequently getting a STATUS_ACCESS_VIOLATION exception under win7
On Wed, 2010-06-09 at 05:07 +, Michael wrote: 2 [main] xterm 2484 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1660 [main] xterm 2484 open_stackdumpfile: Dumping stack trace to xterm.exe.stackdump 2 [main] xterm 536 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x600, errno 11 xterm: Error 29, errno 11: Resource temporarily unavailable Reason: spawn: fork() failed Please provide solution if someone happened to know. 1) BLODA 2) rebaseall Yaakov Cygwin/X -- 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/
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-06-08 15:25:10 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (symlink_info::check): Set h to NULL after closing handle in udf check. Remove overagressive bracketing. Don't set h to NULL without closing the handle. Fix using wrong handle in checking file system when using parent directory handle. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4953r2=1.4954 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.593r2=1.594
Re: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal
There is a similar post from 2009 where the conclusion is that this can be caused by very deep forking (http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it possible that the make script does very deep, or is stuck in infinite, recursion? On 6/8/10, Nasser M. Abbasi n...@12000.org wrote: On 6/7/2010 7:03 PM, Charles Wilson wrote: On 6/7/2010 8:49 PM, Nasser M. Abbasi wrote: $ make test 0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. Error while converting image: No such file or directory Error: Cannot read 'img2.png': No such file or directory Converting image #1 0 [main] perl 4824 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. I wonder if the 'test' procedure for latex2hmtl sets the $PATH to your installed LaTeX implementation. Or worse, somehow sets a PERL5_INCPATH variable to point at the perl/lib/ directory under G:\LATEX\. If THAT happened, then your cygwin-perl would be trying to use native-perl's libraries (including binary extensions)... Try, temporarily, moving G:/LATEX/perl out of the way. -- Chuck Ok, I did. I renamed my windows perl folder, but I still get the same error. May be someone can try to install Latex2html on their cygwin as I did and try this? May be this has nothing to do with windows 64 bit or windows 7, so any windows version might show this problem as well? Installation of l2h is easy on cygwin, just need to download l2h and untar and type ./configure, make, make install, make test Instructions how to install l2h on cygwin are on my page below: http://12000.org/my_notes/l2hwin/index.htm (need to edit one file, to make sure to tell l2h is under Unix) Not many people use l2h under cygwin, may be I am the first to try to do this on cygwin 1.7? == $ ls /cygdrive/G/LATEX | grep -i perl perl_NOT_USED_FOR_MINUTE $ echo $PATH /usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem $ which perl /usr/bin/perl $ perl -v This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int (with 12 registered patches, see perl -V for more detail) $ make test Converting image #2 0 [main] perl 4396 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. Error while converting image: No such file or directory Error: Cannot read 'img2.png': No such file or directory Converting image #1 0 [main] perl 712 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. == --Nasser -- 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: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal
Err, 'very deep' was a bit misleading, the error seemed to show up at 2-3 levels according to the last post in that thread. On 6/8/10, Alexander T mittspamko...@gmail.com wrote: There is a similar post from 2009 where the conclusion is that this can be caused by very deep forking (http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it possible that the make script does very deep, or is stuck in infinite, recursion? On 6/8/10, Nasser M. Abbasi n...@12000.org wrote: On 6/7/2010 7:03 PM, Charles Wilson wrote: On 6/7/2010 8:49 PM, Nasser M. Abbasi wrote: $ make test 0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. Error while converting image: No such file or directory Error: Cannot read 'img2.png': No such file or directory Converting image #1 0 [main] perl 4824 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. I wonder if the 'test' procedure for latex2hmtl sets the $PATH to your installed LaTeX implementation. Or worse, somehow sets a PERL5_INCPATH variable to point at the perl/lib/ directory under G:\LATEX\. If THAT happened, then your cygwin-perl would be trying to use native-perl's libraries (including binary extensions)... Try, temporarily, moving G:/LATEX/perl out of the way. -- Chuck Ok, I did. I renamed my windows perl folder, but I still get the same error. May be someone can try to install Latex2html on their cygwin as I did and try this? May be this has nothing to do with windows 64 bit or windows 7, so any windows version might show this problem as well? Installation of l2h is easy on cygwin, just need to download l2h and untar and type ./configure, make, make install, make test Instructions how to install l2h on cygwin are on my page below: http://12000.org/my_notes/l2hwin/index.htm (need to edit one file, to make sure to tell l2h is under Unix) Not many people use l2h under cygwin, may be I am the first to try to do this on cygwin 1.7? == $ ls /cygdrive/G/LATEX | grep -i perl perl_NOT_USED_FOR_MINUTE $ echo $PATH /usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem $ which perl /usr/bin/perl $ perl -v This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int (with 12 registered patches, see perl -V for more detail) $ make test Converting image #2 0 [main] perl 4396 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. Error while converting image: No such file or directory Error: Cannot read 'img2.png': No such file or directory Converting image #1 0 [main] perl 712 C:\cygwin\bin\perl.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. == --Nasser -- 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: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal
On 6/8/2010 12:46 AM, Alexander T wrote: There is a similar post from 2009 where the conclusion is that this can be caused by very deep forking (http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it possible that the make script does very deep, or is stuck in infinite, recursion? Yes, I know, I saw the above, and I did point that message when I first reported the problem: http://readlist.com/lists/cygwin.com/cygwin/8/44577.html May be then this bug has been there for a year now. --Nasser -- 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: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal
On Jun 8 00:54, Nasser M. Abbasi wrote: On 6/8/2010 12:46 AM, Alexander T wrote: There is a similar post from 2009 where the conclusion is that this can be caused by very deep forking (http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it possible that the make script does very deep, or is stuck in infinite, recursion? Yes, I know, I saw the above, and I did point that message when I first reported the problem: http://readlist.com/lists/cygwin.com/cygwin/8/44577.html May be then this bug has been there for a year now. You missed http://readlist.com/lists/cygwin.com/cygwin/6/34365.html This bug has been fixed for a year now. Your bug is something else. I'm still waiting for some helpful debugging like an strace or, even better, a simple testcase in plain C. 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: Why does /etc/profile include /bin and /usr/bin in the PATH?
On Jun 7 17:17, Christopher Faylor wrote: Maybe this has been discussed and I just don't remember but why are /bin and /usr/bin included in the default path in /etc/profile? History? 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
Error on Files with Hidden Attribute (Novell)
Hi all, $ ls -al ./xls/Thumbs.db ls: cannot access ./xls/Thumbs.db: Input/Output error Thumbs.db has the attribute hidden and is owend by an other user. With $ ls -al ./xls/ ls: cannot access ./xls/Thumbs.db: Input/Output error ?? ? ? ? ?? Thumbs.db The same on local (NTFS) file system works without any complaints. A good time to all Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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: bug report: cygwin 1.7.5, perl *** fatal error TP_NUM_W_BUFS too smal
On 6/8/2010 1:25 AM, Corinna Vinschen wrote: Your bug is something else. I'm still waiting for some helpful debugging like an strace or, even better, a simple testcase in plain C. Corinna If someone using windows 7 out there, can install Latex2html with the current cygwin, they should be able to reproduce this bug (may be this is already done, I do not know). If they can't reproduce it, then this means there is something else on my PC which is causing it. --Nasser -- 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 on Files with Hidden Attribute (Novell)
On Jun 8 10:44, DEWI - N. Zacharias wrote: Hi all, $ ls -al ./xls/Thumbs.db ls: cannot access ./xls/Thumbs.db: Input/Output error Thumbs.db has the attribute hidden and is owend by an other user. With $ ls -al ./xls/ ls: cannot access ./xls/Thumbs.db: Input/Output error ?? ? ? ? ?? Thumbs.db Do you have an strace? 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
'cp' utility bug when dest-name.exe file exist.
$ touch my.exe $ touch some-file $ cp some-file my cp: cannot create regular file `my': File exists $ cp -f some-file my cp: cannot create regular file `my': File exists Same happen ever in cmd.exe so this is not 'bash' fault. -- 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: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 07:47 AM, Oleksandr Gavenko wrote: $ touch my.exe $ touch some-file $ cp some-file my cp: cannot create regular file `my': File exists $ cp -f some-file my cp: cannot create regular file `my': File exists Same happen ever in cmd.exe so this is not 'bash' fault. This is an issue with the fact that cygwin has to support .exe magic. The problem is that cygwin (rightly) refuses to create my if my.exe exists. But which is better? Cygwin doesn't know whether you meant to delete my.exe and replace it with my, or if you meant to replace my.exe but keep the magic suffix. Since we don't know the right hueristics for patching rename(2) (and/or cp(1)) to guess what most people want most of the time, I think that the error message is the best we can do in this particular case of file name conflict. But I'm welcome to the idea of changing coreutils to try and do a more sensible action, if we can get list consensus on what a more sensible action would be. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Why does /etc/profile include /bin and /usr/bin in the PATH?
On Tue, Jun 08, 2010 at 10:26:30AM +0200, Corinna Vinschen wrote: On Jun 7 17:17, Christopher Faylor wrote: Maybe this has been discussed and I just don't remember but why are /bin and /usr/bin included in the default path in /etc/profile? History? /bin and /usr/bin have pointed to the same location for at least ten years. I think that predates /etc/profile. cgf -- 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 on Files with Hidden Attribute (Novell)
On 6/8/2010 4:44 AM, DEWI - N. Zacharias wrote: Hi all, $ ls -al ./xls/Thumbs.db ls: cannot access ./xls/Thumbs.db: Input/Output error Please don't commandeer another thread for your own purposes. If you have something new to report or say that isn't related to an existing thread, just send a new message with a new subject. Replying to an existing thread with a changed subject and topic is discouraged. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: 'cp' utility bug when dest-name.exe file exist.
On Tue, Jun 8, 2010 at 08:01, Eric Blake wrote: On 06/08/2010 07:47 AM, Oleksandr Gavenko wrote: $ touch my.exe $ touch some-file $ cp some-file my cp: cannot create regular file `my': File exists $ cp -f some-file my cp: cannot create regular file `my': File exists Same happen ever in cmd.exe so this is not 'bash' fault. This is an issue with the fact that cygwin has to support .exe magic. The problem is that cygwin (rightly) refuses to create my if my.exe exists. But which is better? Cygwin doesn't know whether you meant to delete my.exe and replace it with my, or if you meant to replace my.exe but keep the magic suffix. Since we don't know the right hueristics for patching rename(2) (and/or cp(1)) to guess what most people want most of the time, I think that the error message is the best we can do in this particular case of file name conflict. But I'm welcome to the idea of changing coreutils to try and do a more sensible action, if we can get list consensus on what a more sensible action would be. -- Eric Blake +1-801-349-2682 Libvirt virtualization library http://libvirt.org This seems to be totally cock-eyed. I couldn't reproduce the OP's results, but then I realized I was using mv instead of cp. cp should behave in the same way as mv and do what I say. I had never encountered this issue and was surprised at some of the things I saw happen when I tried some commands, such as echo foobar foo when I had a foo.exe in the directory. In this case I would expect foo to be created, but instead the output was written to foo.exe. In order to be POSIX-like shouldn't all the tools do exactly what they are told and forget this exe magic? Clearly there is nothing in the underlying file system to prevent us from having both foo and foo.exe in the same directory as can be demonstrated by a simple touch foo foo.exe command. Both files will be created. Both can even have execute permission set via chmod +x foo*. Admittedly this has the potential to confuse the user due to the aforementioned exe magic, but since the order of evaluation should be clearly defined I don't see that as a real problem. Keeping with the Do what I say. approach I would expect entering foo to execute foo, unless foo didn't exist at which the magic gets applied and foo.exe, foo.bat, ... are checked for in whatever the defined order is. If foo.exe is entered then only foo.exe should be looked for and executed if it exists. Why isn't this the way cygwin operates? There certainly appear to be inconsistencies within the tools. Steven Collins -- 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: Why does /etc/profile include /bin and /usr/bin in the PATH?
On Jun 8 10:23, Christopher Faylor wrote: On Tue, Jun 08, 2010 at 10:26:30AM +0200, Corinna Vinschen wrote: On Jun 7 17:17, Christopher Faylor wrote: Maybe this has been discussed and I just don't remember but why are /bin and /usr/bin included in the default path in /etc/profile? History? /bin and /usr/bin have pointed to the same location for at least ten years. I think that predates /etc/profile. Sure. I just meant that we are using the /bin and /usr/bin in $PATH for ages. Personally I thought all the time it's for some sort of Linux $PATH compatibility :) 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: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 08:43 AM, Steven Collins wrote: directory as can be demonstrated by a simple touch foo foo.exe command. Both files will be created. Arguably, both should NOT be created, for the same reasons. That is, it is probably worth a patch to make open(foo.exe,O_CREAT|O_EXCL,mode) fail if foo exists, and open(foo.exe,O_CREAT,mode) delete foo if it exists, effectively renaming foo to foo.exe. which the magic gets applied and foo.exe, foo.bat, You are misunderstanding the magic. It only happens for .exe, and that is because the Unix world is steeped in the tradition of suffix-less executables, but Windows insists on having the .exe suffix for cmd to be able to run an executable. Cygwin goes to various lengths to try to support both, at the expense that you shouldn't have both exist in the same directory. .bat has nothing to do with .exe magic. There certainly appear to be inconsistencies within the tools. Yes, and as they get pointed out, we try to make them more consistent. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 10:52 AM, Eric Blake wrote: On 06/08/2010 08:43 AM, Steven Collins wrote: directory as can be demonstrated by a simple touch foo foo.exe command. Both files will be created. Arguably, both should NOT be created, for the same reasons. That is, it is probably worth a patch to make open(foo.exe,O_CREAT|O_EXCL,mode) fail if foo exists, and open(foo.exe,O_CREAT,mode) delete foo if it exists, effectively renaming foo to foo.exe. I disagree. This seems to me to be adopting the Microsoft policy of doing the user's thinking for them: I don't care what they want - we know what's best for them. If a person wants to have foo and foo.exe in the same directory, that should be allowed. A few times getting tripped up by the wrong thing executing will be a good life lesson for the person, and teach about how different operating systems work to boot. Should I create foo as an executable, and foo.exe exists, then if I want to run foo.exe, I should have to call it out specifically. I can see this might cause some confusion should, unbeknownst to the user, foo.exe exists earlier in the path than foo, but that would become an education on how to use the PATH variable. This confusion arises from Cygwin's kowtowing to Microsoft's dubious idea of using extensions to control the handling of files. As to the automatic deletion/renaming of a file - DON'T EVER DO THIS! As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists which the magic gets applied and foo.exe, foo.bat, You are misunderstanding the magic. It only happens for .exe, and that is because the Unix world is steeped in the tradition of suffix-less executables, but Windows insists on having the .exe suffix for cmd to be able to run an executable. Cygwin goes to various lengths to try to support both, at the expense that you shouldn't have both exist in the same directory. .bat has nothing to do with .exe magic. There certainly appear to be inconsistencies within the tools. Yes, and as they get pointed out, we try to make them more consistent. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org Phil Rising risin...@nationwide.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: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 09:42 AM, risin...@nationwide.com wrote: As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists Huh? Do the copy, then give a failure message? No. A failure message should only occur if the copy failed. Did you mean continue to fail, but make the failure message more friendly? If so: Patches to coreutils welcome. But be aware that this error message uses the equivalent of perror(), where EEXIST would not have quite that wording. In other words, such a patch would be pretty invasive, to recognize the exact errno value that cygwin1.dll returns in this particular failure-to-create case, then massaging just that error case into your desired message, so I probably won't be writing the patch any time soon (I've got higher-priority things on my plate at the moment). Or did you mean change it to succeed, in spite of the naming conflict, in which case there is no failure message and nothing to patch in coreutils. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: 'cp' utility bug when dest-name.exe file exist.
On Tue, Jun 8, 2010 at 10:42 AM, risin...@nationwide.com wrote: I disagree. This seems to me to be adopting the Microsoft policy of doing the user's thinking for them: I don't care what they want - we know what's best for them. If a person wants to have foo and foo.exe in the same directory, that should be allowed. A few times getting tripped up by the wrong thing executing will be a good life lesson for the person, and teach about how different operating systems work to boot. Should I create foo as an executable, and foo.exe exists, then if I want to run foo.exe, I should have to call it out specifically. I can see this might cause some confusion should, unbeknownst to the user, foo.exe exists earlier in the path than foo, but that would become an education on how to use the PATH variable. This confusion arises from Cygwin's kowtowing to Microsoft's dubious idea of using extensions to control the handling of files. If you took away Cygwin's .exe extension handling and just relied on file permissions like Unix, then using Cygwin tools from a cmd.exe prompt would become problematic. Windows wants that .exe (or .bat or .cmd or .msi, etc) extension and doesn't give a whip if you chmod a file's permissions +x. Without an extension, Windows has no idea what to do with the file. That's fine if you never do anything with Cygwin commands outside of a Cygwin shell, but I don't think this is a globally desirable behaviour. -Jason -- 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: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 09:42 AM, risin...@nationwide.com wrote: As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists Huh? Do the copy, then give a failure message? No. A failure message should only occur if the copy failed. Did you mean continue to fail, but make the failure message more friendly? If so: Patches to coreutils welcome. But be aware that this error message uses the equivalent of perror(), where EEXIST would not have quite that wording. In other words, such a patch would be pretty invasive, to recognize the exact errno value that cygwin1.dll returns in this particular failure-to-create case, then massaging just that error case into your desired message, so I probably won't be writing the patch any time soon (I've got higher-priority things on my plate at the moment). Or did you mean change it to succeed, in spite of the naming conflict, in which case there is no failure message and nothing to patch in coreutils. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org Eric - Sorry for the confusion. I understand how it arose. What I meant: 1) IMHO, cp should do the copy. Also, IMHO, there is no naming conflict; foo and foo.exe are not the same name. (I come from a long UNIX background.) No error message should be issued. 2) If cp is going to fail the copy, a more instructive error message would be helpful. I understand the issue with using the generic (this is NOT a bad thing) perror(). But maybe in this case, the cp command could go the extra mile (needed because of Microsoft), and explain the reason for this particular failure if it is going to fail the command. I would not recommend changing perror() - what a mess (not to mention, a ton of work) that would create! Thanks. Phil Rising risin...@nationwide.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: 'cp' utility bug when dest-name.exe file exist.
Greetings, Eric Blake! As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists Huh? Do the copy, then give a failure message? No. A failure message should only occur if the copy failed. Did you mean continue to fail, but make the failure message more friendly? I'm pretty sure he did mean exactly that. But I do see the problem in determining exact case of failure to provide such informative error message. -- WBR, Andrey Repin (anrdae...@freemail.ru) 08.06.2010, 20:04 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: 'cp' utility bug when dest-name.exe file exist.
On Jun 8 12:09, risin...@nationwide.com wrote: On 06/08/2010 09:42 AM, risin...@nationwide.com wrote: As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists Huh? Do the copy, then give a failure message? No. A failure message should only occur if the copy failed. Did you mean continue to fail, but make the failure message more friendly? If so: Patches to coreutils welcome. But be aware that this error message uses the equivalent of perror(), where EEXIST would not have quite that wording. In other words, such a patch would be pretty invasive, to recognize the exact errno value that cygwin1.dll returns in this particular failure-to-create case, then massaging just that error case into your desired message, so I probably won't be writing the patch any time soon (I've got higher-priority things on my plate at the moment). Or did you mean change it to succeed, in spite of the naming conflict, in which case there is no failure message and nothing to patch in coreutils. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org Eric - Sorry for the confusion. I understand how it arose. What I meant: 1) IMHO, cp should do the copy. Also, IMHO, there is no naming conflict; foo and foo.exe are not the same name. (I come from a long UNIX background.) No error message should be issued. There is. foo can mean foo. or foo.lnk, or foo.exe. Cygwin is handling all these names as being the same file. If you stat(foo) Cygwin will return data for foo.exe if it exists. If you try to start an executable foo, and only foo.exe exists, you want to start foo.exe rather than getting a file not found message, I assume. Along the same lines a file foo would hide the file foo.exe and there would be no way for you to access it as foo. That's not desired. Therefore, the transparency of handling foo, foo.exe and foo.lnk as the same file comes with a price. 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: 'cp' utility bug when dest-name.exe file exist.
I disagree. This seems to me to be adopting the Microsoft policy of doing the user's thinking for them: I don't care what they want - we know what's best for them. If a person wants to have foo and foo.exe in the same directory, that should be allowed. A few times getting tripped up by the wrong thing executing will be a good life lesson for the person, and teach about how different operating systems work to boot. Should I create foo as an executable, and foo.exe exists, then if I want to run foo.exe, I should have to call it out specifically. I can see this might cause some confusion should, unbeknownst to the user, foo.exe exists earlier in the path than foo, but that would become an education on how to use the PATH variable. This confusion arises from Cygwin's kowtowing to Microsoft's dubious idea of using extensions to control the handling of files. If you took away Cygwin's .exe extension handling and just relied on file permissions like Unix, then using Cygwin tools from a cmd.exe prompt would become problematic. Windows wants that .exe (or .bat or .cmd or .msi, etc) extension and doesn't give a whip if you chmod a file's permissions +x. Without an extension, Windows has no idea what to do with the file. That's fine if you never do anything with Cygwin commands outside of a Cygwin shell, but I don't think this is a globally desirable behaviour. Just a question: Shouldn't it be up to the user to determine how a file is to be used, and name the file accordingly? If the file is to used only in a Cygwin environment, leave the extension off is desired. If the file is to used in both a Cygwin and a Windows environment, add an extension (like .sh or .exe or whatever is needed). It is easy enough to teach Windows how to recognize what to do with a new extension (like .sh). I am just against operating systems making decisions for the user, or restricting him/her unnecessarily. And, yes, I know that this happens all the time... Phil Risingrisin...@nationwide.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
Cygwin install issue
I installed cygwin 1.5 using the setup-legacy.exe and all the binaries get installed in C:\Cygwin\usr\bin instead of C:\Cygwin\bin and hence the C:\cygwin\cygwin.bat link is broken How do I change the binaries install location from C:\Cygwin\usr\bin to C:\Cygwin\bin thanks in advance, Prakash -- 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: Can't install Fontforge; quot;No such file or directory.quot;
Gregg Levine gregg.drwho8 at gmail.com writes: Hello! Justin for my peace of mind, please enter at a prompt #bzip2 --help or #bzip2 --version. And then report back what that says. (What's inside the quotes of course, the pound mark was used to illustrate a prompt mark.) When I entered #bzip2 --version, Cygwin returned everything below: bzip2, a bock-sorting file-compressor. Version 1.0.5, 10-Dec-2007. Copyright C 1996-2007 by Julian Seward. This program is free software; you can redistribute it and/or modify it under the terms set out in the LICENSE file, which is included in the bzip2-1.0.5 source distribution. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file for more details. bzip2: I won't write compressed data to a terminal. bzip2: For help, type: 'bzip2 --help'. -- 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: Cygwin install issue
On 6/8/2010 12:23 PM, prakash babu wrote: I installed cygwin 1.5 using the setup-legacy.exe and all the binaries get installed in C:\Cygwin\usr\bin instead of C:\Cygwin\bin and hence the C:\cygwin\cygwin.bat link is broken How do I change the binaries install location from C:\Cygwin\usr\bin to C:\Cygwin\bin As 1.5 is legacy, it is no longer supported by this list. So you're really on your own if you still with this version. C:\cygwin\usr\bin should not exist. /usr/bin is supposed to be a mount to C:/cygwin/bin. You can check that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: Why does /etc/profile include /bin and /usr/bin in the PATH?
On 07/06/2010 22:17, Christopher Faylor wrote: Maybe this has been discussed and I just don't remember but why are /bin and /usr/bin included in the default path in /etc/profile? Since they point to the same directory that just slows bash down a little when finding files not in /bin. Some things try to access $0/../share/ Since $prefix=/usr for cygwin, /usr/bin is the expected location. There's no alias for /share like there is for /bin and /lib. 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: Why does /etc/profile include /bin and /usr/bin in the PATH?
On Tue, Jun 08, 2010 at 06:56:48PM +0100, Dave Korn wrote: On 07/06/2010 22:17, Christopher Faylor wrote: Maybe this has been discussed and I just don't remember but why are /bin and /usr/bin included in the default path in /etc/profile? Since they point to the same directory that just slows bash down a little when finding files not in /bin. Some things try to access $0/../share/ Since $prefix=/usr for cygwin, /usr/bin is the expected location. There's no alias for /share like there is for /bin and /lib. That's an argument for having a path which includes /usr/bin. It doesn't explain why both are needed. cgf -- 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: Why does /etc/profile include /bin and /usr/bin in the PATH?
On 08/06/2010 19:27, Christopher Faylor wrote: On Tue, Jun 08, 2010 at 06:56:48PM +0100, Dave Korn wrote: On 07/06/2010 22:17, Christopher Faylor wrote: Maybe this has been discussed and I just don't remember but why are /bin and /usr/bin included in the default path in /etc/profile? Since they point to the same directory that just slows bash down a little when finding files not in /bin. Some things try to access $0/../share/ Since $prefix=/usr for cygwin, /usr/bin is the expected location. There's no alias for /share like there is for /bin and /lib. That's an argument for having a path which includes /usr/bin. It doesn't explain why both are needed. Yep. As far as I know, /bin is superfluous in $PATH and only has to exist in general in order to support explicit /bin/... shebang paths and the like. There could be some analogous reason why some apps required it, but I'd not expect that to arise unless they'd been compiled with $prefix=/, which is of course wrong for cygwin. 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
[ANNOUNCEMENT] new: unison2.40; updated: unison2.32, unison2.27
There are several updates to the Unison packages for Cygwin: * unison2.40 - New Cygwin package. Current beta release upstream. * unison2.32 - Updated; documentation updates only. Current stable release upstream. * unison2.27 - Updated; documentation updates only. Although officially deprecated upstream, this version is still current in e.g. Debian stable/lenny and Ubuntu lucid, so it will continue to be supported in Cygwin for some time. Unison is a file synchronizer for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or on different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other. = Unison packages in Cygwin = Unison is packaged for Cygwin as several independent packages, each providing a version of Unison that is incompatible with the others. You have to run compatible versions of Unison on the client and server, or Unison will issue an error message and quit. Two versions of Unison are compatible if and only if the first two numbers in their version strings are the same. For example, all versions 2.32.* are mutually compatible, and incompatible with versions 2.27.*. By installing one or more of these packages side by side, you can use whichever one you need to synchronize with a particular host. Please read /usr/share/doc/unison*/README.Cygwin for more details. The unison* packages install a convenience symlink from /usr/bin/unison to one of the versioned unison executables, e.g. unison-2.27.exe. alternatives(8) is used to manage the symlink. If the symlink is being managed in auto mode, then it will automatically track the highest numbered version of unison that you have installed. You can override this by either changing the symlink manually with ln(1), or, preferably, by using alternatives(8): alternatives --display unison shows you the installed versions of unison, their priorities, which executable the symlink points to, and whether the symlink is being managed in auto or manual mode. alternatives --config unison presents a menu from which you can choose which version you want to use as the default. This puts the symlink in manual mode. alternatives --auto unison puts the symlink in automatic mode, where it will always point to the highest numbered version of unison that's installed on your host. alternatives --set unison /usr/bin/unison-$V.exe forces the symlink to point to unison-$V.exe, and puts it in manual mode. Please see alternatives(8) for more details. Andrew E. Schulman *** To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: 'cp' utility bug when dest-name.exe file exist.
Ill throw in my two cents. I don't want to overwrite an existing file accidentally. Ie if I ls foo and that writes to foo.exe I would be frustrated. This hasn't happened to me yet so it might not be to big of a problem. It seems a bit odd that the behavior would change if there is a file in the directory of a different name. Preferable I would like cp foo bar, to create a file bar without an extension as opposed to overwriting bar.exe. Anyway its good to have heard about this. mbs On Tue, 2010-06-08 at 12:22 -0400, risin...@nationwide.com wrote: I disagree. This seems to me to be adopting the Microsoft policy of doing the user's thinking for them: I don't care what they want - we know what's best for them. If a person wants to have foo and foo.exe in the same directory, that should be allowed. A few times getting tripped up by the wrong thing executing will be a good life lesson for the person, and teach about how different operating systems work to boot. Should I create foo as an executable, and foo.exe exists, then if I want to run foo.exe, I should have to call it out specifically. I can see this might cause some confusion should, unbeknownst to the user, foo.exe exists earlier in the path than foo, but that would become an education on how to use the PATH variable. This confusion arises from Cygwin's kowtowing to Microsoft's dubious idea of using extensions to control the handling of files. If you took away Cygwin's .exe extension handling and just relied on file permissions like Unix, then using Cygwin tools from a cmd.exe prompt would become problematic. Windows wants that .exe (or .bat or .cmd or .msi, etc) extension and doesn't give a whip if you chmod a file's permissions +x. Without an extension, Windows has no idea what to do with the file. That's fine if you never do anything with Cygwin commands outside of a Cygwin shell, but I don't think this is a globally desirable behaviour. Just a question: Shouldn't it be up to the user to determine how a file is to be used, and name the file accordingly? If the file is to used only in a Cygwin environment, leave the extension off is desired. If the file is to used in both a Cygwin and a Windows environment, add an extension (like .sh or .exe or whatever is needed). It is easy enough to teach Windows how to recognize what to do with a new extension (like .sh). I am just against operating systems making decisions for the user, or restricting him/her unnecessarily. And, yes, I know that this happens all the time... Phil Risingrisin...@nationwide.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 -- 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: 'cp' utility bug when dest-name.exe file exist.
Ok, I would like to jump in this subject, because this is getting me too waay curious... On Wed, Jun 9, 2010 at 01:17, Matthew B. Smith wrote: Ill throw in my two cents. I don't want to overwrite an existing file accidentally. Ie if I ls foo and that writes to foo.exe I would be frustrated. This hasn't happened to me yet so it might not be to big of a problem. It seems a bit odd that the behavior would change if there is a file in the directory of a different name. odd seems like a true description of this .exe magic behaviour. And that is because Cygwin is trying to be more smart than the user itself :) If you took away Cygwin's .exe extension handling and just relied on file permissions like Unix, then using Cygwin tools from a cmd.exe prompt would become problematic. Not exactly. Try this in a cmd.exe: PATHEXT=%PATHEXT%;. Now try running something extensionless... tadaa! CMD magic! :) And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? And to all of you following this subject - there are some interesting answers in this OLD thread: http://www.cygwin.com/ml/cygwin/2007-04/msg00515.html Alas, it is not clear (at least to me) what kind of use cases are we trying to protect with the .exe magic. The cmd.exe launching of executables is solved with the PATHEXT. Is there any more use cases? I'm just reviving this question because I think this could be one of those historic features, which at one point in time turns obsolete but it has always been there... (* wishful thinking alarm*) I am just against operating systems making decisions for the user, or restricting him/her unnecessarily. And, yes, I know that this happens all the time... ditto. And additionally, this is one of those kind of features which is probably a real PITA to maintain (in several packages besides the cygwin itself), fattening the patching over upstream versions... and of course one more big stone to add to the slowness of cygwin. I see several downsides of this feature... and I fail to see the upsides. Please, cgf and corinna, can you shed some light on this? Best regards, ___ Julio Costa -- 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
how to create a wrapper chmod.exe for cygwin 1.7
In cygwin 1.7 chmod does not work with MS DOS style paths and I need to convert these paths to POSIX style paths before doing the chmod Is there a way to create a wrapper chmod.exe that will do this conversion and then perform the chmod operation. thanks, Prakash -- 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 error
On 06/07/2010 08:00 AM, Corinna Vinschen wrote:
I'm not sure about your terminology. With pre-shared key you're
talking about public key authentication, right?
Yes where you put say hostA:~/.ssh/id_dsa.pub into
hostB:~/.ssh/authorized_keys.
If so, I just tested this again with Linux and XP Cygwin clients. From
both clients I can ssh with command as well as scp, connecting with
both, admin and non-admin accounts. So it's not a generic Cygwin
problem afaics. BLODA, maybe?
No, this is just plain Cygwin. Given hcu-g97pnd1, my XP laptop and
usseactxvm01, a 2k3 server, with pre-shared key set up, going from XP -
2K3:
Hcu-g97pnd1:uname -a
CYGWIN_NT-5.1 HCU-G97PND1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwi
Hcu-g97pnd1:ssh usseactxvm01
Last login: Tue Jun 8 17:30:43 2010 from
hcu-g97pnd1.clients.am.health.ge.com
Usseactxvm01:uname -a
CYGWIN_NT-5.2 USSEACTXVM01 1.7.2(0.225/5/3) 2010-03-24 21:12 i686 Cygwin
Usseactxvm01:exit
logout
Connection to usseactxvm01 closed.
Hcu-g97pnd1:ssh usseactxvm01 uname -a
3 [main] sshd 4976 D:\Cygwin\usr\sbin\sshd.exe: *** fatal
error - could not load user32, Win32 error 1114
Hcu-g97pnd1:
So I can ssh to the 2K3 box but if put a command on the end (e.g. uname
–a) it fails. Now redoing that last command but removing my pre-shared
key so that I am prompted for a password:
Hcu-g97pnd1:ssh usseactxvm01
Last login: Tue Jun 8 17:33:10 2010 from
hcu-g97pnd1.clients.am.health.ge.com
Usseactxvm01:mv .ssh/authorized_keys .ssh/authorized_keys.save
Usseactxvm01:exit
logout
Connection to usseactxvm01 closed.
Hcu-g97pnd1:ssh usseactxvm01 uname -a
lf827...@usseactxvm01's password:
CYGWIN_NT-5.2 USSEACTXVM01 1.7.2(0.225/5/3) 2010-03-24 21:12 i686 Cygwin
Hcu-g97pnd1:
Now going from the 2K3 machine - XP machine:
Usseactxvm01:ssh hcu-g97pnd1
Last login: Tue Jun 8 16:24:06 2010 from :0
,
__
.L_
| |
.gQQQ__
| |
g== |
_.---.) |
QQQF= | (^--^)_.-
`; |
Q!| ) ee (
| |
| (_.__._)
/ |
| `--',
,'|
~jjj__, |jgs
)_|--')_| |
jj___ |'
' |
~j__
| |
_jj/ | The Hippo says:
Welcome to |
.{jjj/~
| _|
.{/` | _ _ _ _ _
(_) |
| / ___)| | | | / _ || | |
|| || _ \ |
|( (___ | |_| |( (_| || | |
|| || | | ||
QL___,| \) \__ | \___ | \___/
|_||_| |_||
QQQL___ |(___/
(| |
4___
| |
(=Q | -.-. -.-- --. .-- ..
-.|
(F=
|__|
Hcu-g97pnd1:uname -a
CYGWIN_NT-5.1 HCU-G97PND1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
Hcu-g97pnd1:exit
logout
Connection to hcu-g97pnd1 closed.
Usseactxvm01:ssh hcu-g97pnd1 uname -a
CYGWIN_NT-5.1 HCU-G97PND1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
Usseactxvm01:
--
Andrew DeFaria http://defaria.com
Are the kids on the Barney Show just too damn happy?
--
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: how to create a wrapper chmod.exe for cygwin 1.7
On 6/8/2010 9:55 PM, prakash babu wrote: In cygwin 1.7 chmod does not work with MS DOS style paths and I need to convert these paths to POSIX style paths before doing the chmod Is there a way to create a wrapper chmod.exe that will do this conversion and then perform the chmod operation. How about creating a bash alias which uses cygpath -ua to do the conversion of the parameter? If you need to be able to handle multiple files, you could turn the simple alias into a function the loops through all the parameters, for example. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 13:38, Julio Costa wrote: And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? I can't answer that, but there is a style of symlinks that use .lnk files. Cygwin displays them without that extension, but the actual filename is .lnk so presumably Cygwin has to do some 'lnk-magic' to deal with that. I know it's not the same thing as exe-magic, but it might be related because Cygwin has to hide the reality from the user in order for the symlink to work. On Wed, Jun 9, 2010 at 04:21, Corinna Vinschen wrote: There is. foo can mean foo. or foo.lnk, or foo.exe. Cygwin is handling all these names as being the same file. With symlinks I can understand this, but why match to .exe? Is it because Cygwin allows a user to execute a .exe file without specifying the .exe extension? That is perhaps wrong too - if I want to run foo.exe, I should type ./foo.exe, not ./foo - but ./foo currently works. Then, perhaps this logic was translated into 'cp' (but not 'mv' for some reason?) because people wanted to copy such executables around in the same manner: cp foo bar rather than cp foo.exe bar.exe - but this seems like merely a 'convenience' for Windows users and not a very good one at that. Oh well, yet another thing I suppose to add to my list of ways Windows has set information technology back decades :-P -- David. -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 09, 2010 at 02:38:30AM +0100, Julio Costa wrote: And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? It's already been explained in this very thread. cgf -- 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
new: unison2.40; updated: unison2.32, unison2.27
There are several updates to the Unison packages for Cygwin: * unison2.40 - New Cygwin package. Current beta release upstream. * unison2.32 - Updated; documentation updates only. Current stable release upstream. * unison2.27 - Updated; documentation updates only. Although officially deprecated upstream, this version is still current in e.g. Debian stable/lenny and Ubuntu lucid, so it will continue to be supported in Cygwin for some time. Unison is a file synchronizer for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or on different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other. = Unison packages in Cygwin = Unison is packaged for Cygwin as several independent packages, each providing a version of Unison that is incompatible with the others. You have to run compatible versions of Unison on the client and server, or Unison will issue an error message and quit. Two versions of Unison are compatible if and only if the first two numbers in their version strings are the same. For example, all versions 2.32.* are mutually compatible, and incompatible with versions 2.27.*. By installing one or more of these packages side by side, you can use whichever one you need to synchronize with a particular host. Please read /usr/share/doc/unison*/README.Cygwin for more details. The unison* packages install a convenience symlink from /usr/bin/unison to one of the versioned unison executables, e.g. unison-2.27.exe. alternatives(8) is used to manage the symlink. If the symlink is being managed in auto mode, then it will automatically track the highest numbered version of unison that you have installed. You can override this by either changing the symlink manually with ln(1), or, preferably, by using alternatives(8): alternatives --display unison shows you the installed versions of unison, their priorities, which executable the symlink points to, and whether the symlink is being managed in auto or manual mode. alternatives --config unison presents a menu from which you can choose which version you want to use as the default. This puts the symlink in manual mode. alternatives --auto unison puts the symlink in automatic mode, where it will always point to the highest numbered version of unison that's installed on your host. alternatives --set unison /usr/bin/unison-$V.exe forces the symlink to point to unison-$V.exe, and puts it in manual mode. Please see alternatives(8) for more details. Andrew E. Schulman *** To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
