Re: Cygwin Setup crashes Windows 2000 during preremove script libusb-win32 0.1.12.1-2
At 00:08 2009-07-10 +0100, you wrote: During Cygwin Setup noticed system crash, while setup screen displayed something like: Running preremove script libusb-win32 Attempting to isolate the problem I told setup to keep the current version of libusb-win32 and setup installed everything else apparently fine. After this I tried running setup again with only this attempted update: libusb-win320.1.12.1-2 -0.1.12.2-1 this again leads to a sudden system reset. Questions: 1. Am I correct in understanding this is not the intended behaviour? Nah, it's not some kind of reset-to-complete-install thing, if that's what you're wondering. There must be a bug in the libusb driver when it's told to unload. 2. What is the best way to work around (or solve) this problem? Start-Run-devmgmt.msc. Select View menu - Show hidden devices. Expand the Non-Plug and Play Drivers. Find libusb. Dunno exactly what it's called, but it should be fairly obvious; to check, when you find it, double-click it to bring up the properties. Switch to the Driver tab and click Driver Details; if the driver is called libusb0.sys, that's the right one. Switch back to the General tab, click the Device usage drop-down, select Do not use this device (disable). Click OK, exit everything, reboot. You should now be able to run setup having booted without libusb running, so it won't have to unload to be replaced and won't crash doing so. 3. Who drove Igor Peshansky away? (So we may lynch him and bring Igor back.) The hippos sent a ransom note... but we can't read it, as it's covered with a brown substance that sounds like a bell. cheers, DaveK Hi Dave, Thanks for your quick reply. Couldn't find libusb among Non-Plug and Play Drivers. Also libusb0.sys can only be found at: E:\cygwin\lib\libusb\ not at: C:\WINNT\system32\drivers\ This suggests that E:\cygwin\usr\sbin\libusb-uninstall either completed anyway before the crash, or libusb0.sys was never properly installed to begin with? By the way: testlibusb returns: Dev #0: - And testlibusb-win shows: DLL version: 0.1.12.1 Driver version: -1.-1.-1.-1 bus/device idVendor/idProduct Having a closer look at libusb-install and libusb-uninstall reveals that running /usr/lib/libusb/install-filter crashes Windows. (Also when I try to redo libusb-install from a bash prompt.) So this means something in Windows (or another part of Cygwin?) changed to cause the install-filter.exe program to now crash the OS? Assuming the new version would work correct would a workaround be to replace the old install-filter.exe program with something more innocent like the E:\cygwin\bin\echo.exe program? (Assuming that after that Cygwin Setup would install the new libusb version with a new, corrected install-filter.exe?) cheers, Arend-Jan. -- 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 Setup crashes Windows 2000 during preremove script libusb-win32 0.1.12.1-2
At 02:37 2009-07-10 +0200, you wrote: At 00:08 2009-07-10 +0100, you wrote: During Cygwin Setup noticed system crash, while setup screen displayed something like: Running preremove script libusb-win32 Attempting to isolate the problem I told setup to keep the current version of libusb-win32 and setup installed everything else apparently fine. After this I tried running setup again with only this attempted update: libusb-win320.1.12.1-2 -0.1.12.2-1 this again leads to a sudden system reset. Questions: 1. Am I correct in understanding this is not the intended behaviour? Nah, it's not some kind of reset-to-complete-install thing, if that's what you're wondering. There must be a bug in the libusb driver when it's told to unload. 2. What is the best way to work around (or solve) this problem? Start-Run-devmgmt.msc. Select View menu - Show hidden devices. Expand the Non-Plug and Play Drivers. Find libusb. Dunno exactly what it's called, but it should be fairly obvious; to check, when you find it, double-click it to bring up the properties. Switch to the Driver tab and click Driver Details; if the driver is called libusb0.sys, that's the right one. Switch back to the General tab, click the Device usage drop-down, select Do not use this device (disable). Click OK, exit everything, reboot. You should now be able to run setup having booted without libusb running, so it won't have to unload to be replaced and won't crash doing so. 3. Who drove Igor Peshansky away? (So we may lynch him and bring Igor back.) The hippos sent a ransom note... but we can't read it, as it's covered with a brown substance that sounds like a bell. cheers, DaveK Hi Dave, Thanks for your quick reply. Couldn't find libusb among Non-Plug and Play Drivers. Also libusb0.sys can only be found at: E:\cygwin\lib\libusb\ not at: C:\WINNT\system32\drivers\ This suggests that E:\cygwin\usr\sbin\libusb-uninstall either completed anyway before the crash, or libusb0.sys was never properly installed to begin with? By the way: testlibusb returns: Dev #0: - And testlibusb-win shows: DLL version: 0.1.12.1 Driver version: -1.-1.-1.-1 bus/device idVendor/idProduct Having a closer look at libusb-install and libusb-uninstall reveals that running /usr/lib/libusb/install-filter crashes Windows. (Also when I try to redo libusb-install from a bash prompt.) So this means something in Windows (or another part of Cygwin?) changed to cause the install-filter.exe program to now crash the OS? Assuming the new version would work correct would a workaround be to replace the old install-filter.exe program with something more innocent like the E:\cygwin\bin\echo.exe program? (Assuming that after that Cygwin Setup would install the new libusb version with a new, corrected install-filter.exe?) Tried it (replacing install-filter.exe with echo.exe). (See attached log file.) This works in the sense that there is no crash and install-filter.exe is replaced by a new version on install. However there is still no libusb to be found among Non-Plug and Play Drivers, nor is there a libusb0.sys to be found underneath the WINNT directory. Also except for the DLL version number (which is now: 0.1.12.2), the output of testlibusb and testlibusb-win is the same as before. This makes me wonder if the installation process isn't flawed to begin with? If any one is interested I could check if the new install-filter.exe also crashes Windows 2000? I always wonder why people take the trouble to put flaws in their programs?2009/07/10 03:09:16 Starting cygwin install, version 2.573.2.3 2009/07/10 03:09:16 Current Directory: E:\download\Utilities\Shells\Cygwin\installInto 2009/07/10 03:09:16 Changing gid to Users 2009/07/10 03:09:16 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2009/07/10 03:09:49 source: network install 2009/07/10 03:09:51 root: E:\cygwin binary system 2009/07/10 03:09:53 Selected local directory: E:\download\Utilities\Shells\Cygwin\installInto 2009/07/10 03:09:55 net: Direct Loaded cached mirror list get_url_to_membuf http://cygwin.com/mirrors.lst getUrlToStream http://cygwin.com/mirrors.lst 2009/07/10 03:10:03 site: http://ftp.inf.tu-dresden.de/software/windows/cygwin32/ get_url_to_membuf http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2 getUrlToStream http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2 get_url_to_membuf http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2.sig getUrlToStream http://ftp.inf.tu-dresden.de/software/windows/cygwin32//setup.bz2.sig Checking MD5 for file://E:\download\Utilities\Shells\Cygwin\installInto/http%3a%2f%2fftp.inf.tu-dresden.de%2fsoftware%2fwindows%2fcygwin32%2f/release/libusb-win32/libusb-win32-0.1.12.2-1.tar.bz2 MD5 verified OK:
Obfuscation fails.
In the last 8 hours I have received 4 spam e-mails on the forwarding address I use exclusively for this list. (Have never received any spam on it before.) This might suggest the level of obfuscation for e-mail addresses displayed on this list needs to be upgraded. My current Cygwin e-mail address will self destruct within 5 minutes from sending this e-mail. Best regards, Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: backspace key in gvim
At 11:41 2006-03-19 +0800, Steven Woody wrote: snip It would appear that you have missed the answer of Igor Peshansky in: http://cygwin.com/ml/cygwin/2006-03/msg00522.html Which is very unfortunate since, as usual, his answer is of a very high quality. Refrasing it: vim +h i_backsp and vim +h i_BS give you your answer. HTH, Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Missing keyboard layout
At 10:14 2006-03-01 +, Dagur Páll Ammendrup wrote: snip Btw, you need to update your FAQ to point to http://www.microsoft.com/globaldev/reference/keyboards.mspx the current link doesn't work. http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-submit-layout still lacks this correction? I can't link directly to my layout but if you select Icelandic from the list you will get it (doesn't work in firefox). snip Direct link to Icelandic keyboard layout: http://www.microsoft.com/globaldev/keyboards/kbdic.htm WFM in Internet Exploder. HTH, Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: backspace key in gvim
At 23:42 2006-03-18 +0800, Steven Woody wrote: hi, i've installed gvim on cygwin, but the backspace does not work properly. the problem is, in insert mode, the backspace key can not delete any character which are typed before current insert mode ( it can only delete chars typed in this insert session ). is there any clue? thanks. -- steven woody (id: narke) snip As far as I know vi has always worked like that. Just as when you set Auto Indent mode with: :set ai you cannot move to before the initial indentation point with backspace, but have to use Ctrl-d instead. Taking your message at face value one might think you would be happier with using gvim in easy mode: gvim -y However I think using that mode subtracts much more from the strong points of vi than it does from its weak points. There is also the question of whether this question is on topic for this list. So are you someone who is experienced with gvim on other systems and do you find the behavior on Cygwin unexpected? (In that case your question is on topic for this list and I cannot answer it.) Or are you a novice using vi? In that case your question is probably off topic for this list. I would be happy to supply you in that case with a more extensive answer on e.g. the Cygwin-Talk mailinglist: http://cygwin.com/ml/cygwin-talk/ You could also pose your question to a vi specific forum instead. Arend-Jan Westhoff -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sshd and scp/sftp: slow throughput on windows machines
At 02:49 2006-03-18 +0100, Max Stein wrote: Unfortunately, the performance of the cygwin sshd server is very poor when it comes to copying large files. I have made this observation on several new and fast machines (3 GHz, 512 MB RAM, 100 MB/s Intel Pro network card) running with Windows XP or Windows 2003 Server. The best speed achievable was about 4 MB/s when copying a file from the SSH client to the SSH server; when doing it the other way round, the throughput was even worse, about 2.3 MB/s. I tried it on three different machines running the newest version of cygwin's sshd und scp/sftp. The results were approximately the same. Neither the client's nor the server's processor was really busy. The CPU usage oscillated around 30-40%. Setting up the same scenario on linux yielded a completely different picture. Using the Knoppix disc 4.0.2 on the client and the server machine I easily achieved a throughput of 10.8 MB/ in both directions (pushing a file to the server or downloading a file from it). What could be done to improve the performance of cygwin's SSH server? There were already some older posts dealing with the same problem but nobody had really a constructive idea or proposal. 1. Is it possible to increase the bandwith by having the client aggregate multiple sessions through a single pipe? 2. It would seem that PPTP connections can be much faster. E.g. a FreeBSD MPD running on a 400 Mhz Pentium II can sustain a 50 Mbit/s datastream at a CPU usage of 25%. W2k and XP have easy to configure PPTP clients. (See also W2003 RAS.) HTH, Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sshd and scp/sftp: slow throughput on windows machines
At 22:52 2006-03-18 +0100, Max Stein wrote: 1. Is it possible to increase the bandwith by having the client aggregate multiple sessions through a single pipe? Could you please give me some advice how this can be achieved? I am not an SSH guru yet. Unfortunately neither am I. It was an idea derived from a report on the stunnel program: http://ftp.surfnet.nl/networking/stunnel/ that tunnels through SSL and according to the report can do such aggregation. (I don't know an english version of this report so I'll refrain from providing a link to that.) Since neither the CPU nor the network bandwidth is fully used in your case it would seem at least theoretically possible that the same could be done with transport over SSH. I formulated it as a question because I am not absolutely sure and don't know the details myself. snip W2k and XP have easy to configure PPTP clients. (See also W2003 RAS.) Why should a point to point tunnel improve the performance? Using Linux on the client and server machines I achieved a throughput of 10.8 MB/s whereas the theoretical maximum on a 100 MBit/s ethernet network would be 12.5 MB/s. There must be another way. Why is the Linux implementation of SSH able to provide a much better throughput for scp/sftp than cygwin's implementation running on the same hardware? It is not a problem of the Windows operating system because usual FTP tranfer yields simalar fast throughput of 10-11 MB/s like SSH running on Linux. Ah, so your first MB was Megabit and the others were MegaByte... To prevent any more misunderstandings: Are you talking about the Windows FTP or the Cygwin FTP here? Anyway, it seems not too far fetched to assume that anything that runs directly on a native (i.e. Windows or Linux) OS would outperform a similar thing running through an emulation layer (Cygwin). Arend-Jan Westhoff -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: _kbhit
At 18:58 2006-02-10 -0500, Michiel de Hoon wrote:
On Sun, Feb 05, 2006 at 01:17:33PM -0500, Michiel De Hoon wrote:
For one of my software projects, I need the _kbhit function to check the
console for keyboard input. While this function is present in msvcrt.dll,
it
is missing from cygwin1.dll, so I started writing this function myself
(I'm
hoping to contribute it to Cygwin if it works well).
I really appreciate the sentiment of submitting code but _kbhit is not a
linux function (or echo onPOSIX, POSIX, POSIX.../echo off) so it
really isn't a candidate for inclusion in the Cygwin DLL.
=20
cgf
Even though _kbhit is not a POSIX function, I think a valid argument can be
made to include it in Cygwin anyway.
First, some Cygwin programs will need this function to be able to interact
with the Windows OS. Second, as the Cygwin DLL is a replacement for msvcrt
(and msvcrt.dll and cygwin1.dll cannot be used together), [snip]
I cannot confirm your assertion that msvcrt.dll and cygwin1.dll cannot be
used
together. If I compile the attached (almost C) file that dynamically links to
msvcrt.dll using Cygwin:
gcc -o kbhit.exe kbhit.cpp
it compiles, links and works (on CMD and bash on CMD but not on rxvt; as
stated elsewhere in this thread the Microsoft _kbhit is not very good).
HTH,
Arend-Jan Westhoff.#include stdio.h
#include windows.h
extern C {
typedef int (*int_function_void_t)(void);
HINSTANCE gimmeMSVCRT() {
static HINSTANCE retval = LoadLibrary(MSVCRT.DLL);
return retval;
}
int _kbhit(void) {
static int_function_void_t f = (int_function_void_t)
GetProcAddress(gimmeMSVCRT(), _kbhit);
return f();
}
} // extern C
int main() {
printf(Hit me!); fflush(stdout);
while(!_kbhit())
;
printf(\nOuch!!\n);
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
At 00:37 2005-10-26 -0400, Igor Pechtchanski wrote: On Wed, 26 Oct 2005, Arend-Jan Westhoff wrote: Could this for once mean a positive press for text mounts? Or has it something to do with NTFS - FAT32 ? The former is unlikely. The latter is possible. If the latter is true I think that would be bad. (For more: see remark on filesystems below.) How come that if I have text mounts the edit action in the preceding procedure only ads a linefeed but no carriage return? [snip] Ah, because vim has default fileformats=unix,dos instead of dos,unix! Vim autodetects to the mode the file was in. Since you only had one line in your file and no EOL, vim defaulted to Unix fileformat. I thought that was exactly what I was saying with the added bonus of pointing people into the direction how to change it if they want to... (I am sorry I am not as clear a writer as I wish I was.) Though I cannot reproduce the problem I do support those who experience it and want it changed because: -I don't think changing it significantly impacts functionality on other OSs. Huh? Well: 1. The most important other OS is Linux and since that is case sensitive its vim won't be affected by something that affects only case insensitive OSs. (Except perhaps performance wise, but I deem that will be negligible.) (Btw with regard to performance. If I run: bash -c time vim +q and look at the times, I think that compared to a few months ago this and other timings have improved by a factor of 3 to 4. Probably due to compiler modifications. Good work and thanks people!) 2. It would be possible (though perhaps undesirable) to make a Cygwin exception which, by definition, will not impact other OSs. -Whether or not it is a vim bug is irrelevant. What is relevant that it is clearly undesirable behavior. (If vim is the appropriate place to change it it should be done there.) The part of the behavior that's undesirable is creating a new file (i.e., changing the inode). If the file is written in-place (i.e., the inode remains the same), file name changes are irrelevant. Huh? That is not what the OP says: http://cygwin.com/ml/cygwin/2005-10/msg00646.html He only talks about case change and not about inodes. FWIW if I repeat the testcases in my previous post: http://cygwin.com/ml/cygwin/2005-10/msg00875.html and look at inodes I find that the inode does not change. So that is a problem I cannot reproduce either. Also please note that my version is actually somewhate newer than that reported by the OP: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 21 2005 13:43:01) cygcheck.out gives: vim 6.4-2 Can anyone confirm whether any problem with case or inodes as reported in this thread still persists in this version? If it depends on things like filesystems or other local details this is a bad thing, since it implies that a script that runs without problems on one drive/system, may unexpectedly fail on another. -I think the rule should be that where ever a Cygwin utility uses a filename of an existing file it should use the actual name on disk and not the characters the user happened to type. (Wasn't that using something like: _findfirst() ?) (So the dump statement above should not display zz: but ZZ: on its first line of output.) Add check_case:adjust to $CYGWIN for this behavior. Are you saying that you now think differently about this option as in: http://www.cygwin.com/ml/cygwin/2005-01/msg00057.html where you called it pointless, useless and you had nothing against its removal? Anyway the point I was trying to make is not for having to use yet another obscure option that nobody is willing to support but to point out that there is no value in the current default and to advocate a different one. (Which might resemble check_case:adjust. I remember looking at it, probably last year, but apparently I have made no notes of that.) As an illustration of how people can be wrongfooted (twice) by the current default that would be remedied if replaced by the one I propose please imagine the following: -Preparation the user doesn't know about (or doesn't recall): There exists an empty file: x.sh : rm x.sh touch x.sh -User edits: vim X.sh (Thinking he creates the file.) Wrongfooting 1: Vim only talks about: X.sh, e.g. on the titlebar, or when writing the file: X.sh 1 line, 2 characters written -Wrongfooting 2: User checks file X.sh exists by running: ls X.sh which shows: X.sh -In reality all that exists is still: x.sh -User edits again: vim x.sh -Runs: ls Sees: x.sh And user concludes wrongfully that vim has transformed X.sh into x.sh. -Instead of blaming the user I blame the default and propose to change it. (Any similarity between this and OP post might or might not be totally accidental.) Please note that changing this default would also provide some explanation to a user why: ls
Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
At 15:32 2005-10-24 +0200, Corinna Vinschen wrote: On Oct 20 14:16, Shankar Unni wrote: Christopher Faylor wrote: On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote: Supposed, you have a file X.sh ( exactly in this spelling ). If you enter: vim x.sh ( also exactly in this spelling ) and write it back after any modification, the file will be renamed even to x.sh. This isn't a vim problem. Windows filename handling is case-insensitive. But I think it's worth mentioning that 6.3 doesn't do this (change the case of the name when writing back). It overwrites the old file when writing back, thus preserving its case. No, it doesn't. I just tried it in 6.3 and this behaviour is the same as in 6.4. There is special code in the native Windows port which tests explicitely for the case of the filename, but that's not in the UNIX code which is used for Cygwin. Corinna I cannot reproduce this problem: (Explanatory notes in (). If you don't need them please ignore them.) The procedure creates or overwrites file ZZ: (Should work on both cmd and Cygwin bash. On cmd must have Cygwin\bin dir in PATH.) echo -n ZZ ZZ ( relevance: Use Cygwin echo even on cmd. May be here not strictly necessary, but instructive: In general also return and linefeed will be executed when a vim script is sourced.) (Please note that if a file like Zz preexisted that will still be its name, so:) rename ZZ ZZ (At this point we have a file named: ZZ with contents: ZZ) Now running one of the following two statements produces the same results on my system: vim +s/Z/y/g -s ZZ zz vim +s/Z/y/g +wq zz (Yes, I am violating the standard that files should end with newline, but not relevant IMO.) Results: ls [zZ][zZ] produces: ZZ So no case change: I cannot reproduce the problem. cat zz produces: yy Which shows the edit action was successful. Could this for once mean a positive press for text mounts? Or has it something to do with NTFS - FAT32 ? How come that if I have text mounts the edit action in the preceding procedure only ads a linefeed but no carriage return? dump zz produces: zz: 7979 0a yy. Ah, because vim has default fileformats=unix,dos instead of dos,unix! My cygcheck.out is still the same: http://cygwin.com/ml/cygwin/2005-10/txt00018.txt Though I cannot reproduce the problem I do support those who experience it and want it changed because: -I don't think changing it significantly impacts functionality on other OSs. -Whether or not it is a vim bug is irrelevant. What is relevant that it is clearly undesirable behavior. (If vim is the appropriate place to change it it should be done there.) -I think the rule should be that where ever a Cygwin utility uses a filename of an existing file it should use the actual name on disk and not the characters the user happened to type. (Wasn't that using something like: _findfirst() ?) (So the dump statement above should not display zz: but ZZ: on its first line of output.) (Except of course where the user provides a new name as with the command: rename, or when writing to a different file from vim. One can still use filename completion to match an existing file's name if one wants to.) Please note that my proposal is also in line with the native OS: E.g. Cygwin dir and ls have such problem, the native cmd dir has not: ls zz produces: zz but cmd /c dir /B zz produces ZZ Arend-Jan Westhoff. PS Speaking of filename completion: Windows can be configured to use TAB as cmd file and directory expansion character. I do find the cmd filename completion behaviour more convenient than the default bash version. It is usually not difficult to organize a directory so that TAB or SHIFT-TAB find the desired file/dir quickly. On bash you default get a beep and filename expansion stops whenever there is more than one choice. I hate that. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion client text mounts
At 11:27 2005-10-24 +0200, Joerg Schaible wrote: Hello Subversion maintainer, the subversion client does unfortunately not respect text mounts. Checking = out form a remote repository all text files have unix line endings although= they have the property svn:eol-style set to native. This is a major hassle= in a build environment where also a lot of non-Cygwin tools have to be use= d. - J=F6rg Hello Joerg, Am not the Subversion maintainer, but have some possible workarounds: 1. Use the native Windows subversion. (I do.) http://subversion.tigris.org/project_packages.html#binary-packages 2. Use u2d (d2u). HTH Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Mailing list confusion
At Thu, 24 Mar 2005 00:06:30 -0800 Brian Dessent wrote: Arend-Jan Westhoff wrote: How come when I look at http://sources.redhat.com/ml/cygwin/2005-03/index.html: I see the message: March 24, 2005 07:32 Re: Path confusion Brian Dessent That message lists: 07:17 Path confusion Luke Kendall As its reference, but Luke's message has no Follow Up to Brian's? Also when I look at the thread index: http://sources.redhat.com/ml/cygwin/2005-03/threads.html Luke's message is listed but Brian's is not. I think you caught the ML archives page at a point at which it was re-indexing. Both URLs above display both messages with the correct threading for me. An even stronger example: March 24: 06:15 Re: installing identical cygwin configurations on multiple systems fergus and March 23: 19:56 installing identical cygwin configurations on multiple systems Greg Vaidman Have neither a Reference nor a Follow Up to the other (though the thread index looks normal?). The reply email did not contain a References: or In-reply-to: header, so the archives did not know it was a reply. Proper email readers and archive software depend on one or both of those headers to preserve threads. Some brain dead email programs (cough Outlook cough) instead just go by subject, and are too ignorant to add the headers that preserve the threading. That means that messages created in those programs break threading in the archives, and those programs cannot cope with threads where the subject is changed mid-thread. Brian Thanks Brian, for the clarification. Does this imply that if one is e.g. on the digest version of the mailinglist (as I am, and would like to stay that way), that this confusion will be inevitable when one replies to a message or is there a work around? (Actually I'm in fact responding to your reply from the archive since the digest version with your reply has not yet arrived.) Would it not be convenient if the archive and mailinglist present a line one could copy and paste as the first line of a reply so that threading info would be correctly preserved? (Should make it independent of any rogue e-mail clients as well.) (Btw http://sourceware.org/ml/cygwin/ is apparently a different -- may be more proper(?) -- name to refer to the location of the Cygwin archive (currently at IP 12.107.209.250).) Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Mailing list confusion
How come when I look at http://sources.redhat.com/ml/cygwin/2005-03/index.html: I see the message: March 24, 2005 07:32 Re: Path confusion Brian Dessent That message lists: 07:17 Path confusion Luke Kendall As its reference, but Luke's message has no Follow Up to Brian's? Also when I look at the thread index: http://sources.redhat.com/ml/cygwin/2005-03/threads.html Luke's message is listed but Brian's is not. An even stronger example: March 24: 06:15 Re: installing identical cygwin configurations on multiple systems fergus and March 23: 19:56 installing identical cygwin configurations on multiple systems Greg Vaidman Have neither a Reference nor a Follow Up to the other (though the thread index looks normal?). Looks to me like there's something broken. Arend-Jan Westhoff. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: off topic
At: Wed, 16 Mar 2005 08:34:32 + (UTC) rubinet rgraziosi at gujm dot it wrote: Sorry for my bad english and to be off topic I'm a journalist from Italy. I urgently need to make a couple a questions to a motorola employee. Are you *real* motorolan? Can you help me? Thank you very much! What about trying (variants of): http://www.google.it/search?hl=itq=%22motorola+employee%22+%22work+*+motoro la%22lr= http://www.google.it/search?hl=itq=cygwin+%22work+*+motorola%22lr= http://www.motorola.com/ http://www.motorolacareers.com/moto.cfm?cntry=Italy http://www.motorola.com/mediacenter/bios Arend-Jan Westhoff -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: req: using cygwin's gcc for creating static libs in msvc binary format (.a = .lib) # Re: static MSVC library?
Hi,
I am opening this thread again , more than 5 years later :
@ http://sources.redhat.com/ml/cygwin/1999-09/msg00541.html [1]
How comes is it impossible to write a STATIC lib using msvc's .LIB
format ? while .DLL are possible ?
Or at least to transcribe from gcc's .a format ?
Anyway if it possible or not this should be somewhere in the FAQ.
thx
Am not an expert but have tried the following for you:
Source files:
hello.h:
void hello();
hello.c:
#include stdio.h
void hello() {
printf(Hello World\n);
}
main.c:
#include hello.h
int main() {
hello();
return 0;
}
Building and using library using Cygwin:
gcc -c hello.c
ar cr hello.lib hello.o
gcc -o hellolib.exe main.c hello.lib
Leads to a working program. This last step using the Cygwin created library
also leads to a working program when using Microsoft's VC++ 6.0.
Instead of ar I have also used Microsofts lib.exe (should be available from:
http://msdn.microsoft.com/visualc/vctoolkit2003/
) successfully.
E.g. when applied on the gcc compiled hello.o file:
lib hello.o
creates
hello.lib
which can again be successfully linked with using either gcc or VC++.
It looks like changing a lib.a into a lib.lib might require only a rename!
(But I remember reading that debug formats differ between gcc and VC.)
Some additional info:
http://www.network-theory.co.uk/docs/gccintro/gccintro_65.html
http://www.network-theory.co.uk/docs/gccintro/gccintro_16.html
http://www.linuxquestions.org/questions/archive/9/2003/10/3/105795
http://www.linuxlookup.com/HOWTO/GCC-HOWTO/x575.html#AEN579
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/h
tml/_core_lib_reference.asp
http://www.cygwin.com/faq/faq_3.html#SEC103
http://www.cygwin.com/faq/faq_3.html#SEC102
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
cygpath --help - crash
When running: cygpath --help apparently a crash occurs. Output: Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME... 68 [main] cygpath 1964 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 25808 [main] cygpath 1964 open_stackdumpfile: Dumping stack trace to cygpath.exe.stackdumpException: STATUS_ACCESS_VIOLATION at eip=610D90E1 eax= ebx=0001 ecx= edx=0068 esi=0015 edi=0068 ebp=0022D858 esp=0022D854 program=E:\cygwin\bin\cygpath.exe, pid 1988, thread main cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023 Stack trace: Frame Function Args 0022D858 610D90E1 (0068, 0022D8FE, 0040115C, 0001) 0022ECF8 610DCB8F (0022F168, 610F6D68, 00401100, 0022ED54) 0022ED18 610DC5F8 (610F6D68, 00401100, 0022ED48, ) 0022ED38 610DE31F (610F6D68, 00401100, 0022EFD4, 0022EFD4) 0022ED58 610938EF (610F6D68, , 00404170, 00404000) 0022EFB8 00402BA8 (0002, 0A050158, 0A0500A8, 0001) 0022F008 610064A3 (0022F020, 00030002, 00050004, 00070006) 0022FF88 610066B0 (, , , ) End of stack trace Cygwin Configuration Diagnostics Current System Time: Sat Mar 05 10:34:40 2005 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Program Files\Common Files\Adaptec Shared\System E:\cygwin\usr\local\bin E:\cygwin\usr\bin E:\cygwin\bin E:\cygwin\usr\X11R6\bin D:\Program Files\rksupport D:\Program Files\Subversion\bin E:\Borland\BCC55\Bin D:\Program Files\7-Zip D:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin D:\Program Files\Microsoft Visual Studio\Common\Tools D:\Program Files\Microsoft Visual Studio\VC98\bin D:\uts . Output from E:\cygwin\bin\id.exe (nontsec) UID: 1000(-) GID: 513(None) 513(None) Output from E:\cygwin\bin\id.exe (ntsec) UID: 1000(-)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT Path = `C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program Files\Common Files\Adaptec Shared\System;E:\cygwin\usr\local\bin;E:\cygwin\usr\bin;E:\cygwin\bin;E:\cygwin\usr\X11R6\bin;D:\Program Files\rksupport;D:\Program Files\Subversion\bin;E:\Borland\BCC55\Bin;D:\Program Files\7-Zip;D:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;D:\Program Files\Microsoft Visual Studio\Common\Tools;D:\Program Files\Microsoft Visual Studio\VC98\bin;D:\uts;' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\-\Application Data' APR_ICONV_PATH = `D:\Program Files\Subversion\iconv' CLASSPATH = `C:\Program Files\Java\j2re1.4.1_03\lib\ext\QTJava.zip' CommonProgramFiles = `C:\Program Files\Common Files' COMPUTERNAME = `LAMPION' ComSpec = `C:\WINNT\system32\cmd.exe' DIRCMD = `/ogn' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\-' include = `D:\Program Files\Microsoft Visual Studio\VC98\atl\include;D:\Program Files\Microsoft Visual Studio\VC98\mfc\include;D:\Program Files\Microsoft Visual Studio\VC98\include' lib = `D:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;D:\Program Files\Microsoft Visual Studio\VC98\lib' LOGONSERVER = `\\LAMPION' MSDevDir = `D:\Program Files\Microsoft Visual Studio\Common\MSDev98' NTRESKIT = `D:\Program Files\rksupport' NUMBER_OF_PROCESSORS = `2' OS = `Windows_NT' Os2LibPath = `C:\WINNT\system32\os2\dll;' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0501' ProgramFiles = `C:\Program Files' PROMPT = `$P$+$G' QTJAVA = `C:\Program Files\Java\j2re1.4.1_03\lib\ext\QTJava.zip' SystemDrive = `C:' SystemRoot = `C:\WINNT' TEMP = `C:\DOCUME~1\-\LOCALS~1\Temp' TMP = `C:\DOCUME~1\-\LOCALS~1\Temp' tvdumpflags = `10' USERDOMAIN = `LAMPION' USERNAME = `-' USERPROFILE = `C:\Documents and Settings\-' windir = `C:\WINNT' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0020 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `E:\cygwin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `E:\cygwin/bin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Re: cygpath --help - crash
When running: cygpath --help apparently a crash occurs. Output: Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME... 68 [main] cygpath 1964 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 25808 [main] cygpath 1964 open_stackdumpfile: Dumping stack trace to cygpath.exe.stackdump Oeps forgot to add the version information, cygpath --vesion: cygpath (cygwin) 1.37 Path Conversion Utility Copyright 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. Compiled on Mar 1 2005 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug diff 2.8.7: Separate dir
Thanks for the explanation. However I don't quite understand this is what one would want. With regard to paths I would expect one to want: A Windows or Posix style path is converted to one internal path format. After this conversion the behaviour is independent of whatever the original format was. In my opinion diff clearly violates this behaviour. Also on reading the User's manual chapter Mapping path names I get the idea that the behaviour I would want is described there. I quote: Cygwin supports both Win32- and POSIX-style paths, where directory delimiters may be either forward or back slashes. ..., Cygwin maintains a special internal POSIX view of the Win32 file system that allows these programs to successfully run under Windows. Cygwin uses this mapping to translate between Win32 and POSIX paths as necessary. It also seems inconsequent if what you say is truely correct and what is intended that when I use my file 'a' from my original example and do the following: copy a b that then: diff ./a .\b says that the files are completely different, whereas: diff ./a .\a says they are completely equal, while files a and b are character for character identical! Text - Binary mode. It is not so much a directory structure or mount that is text or binary, rather it is an individual file that is either text or binary. What can be described for a mount is an intention on the production of text files on that mount: to use only LF or CRLF e.g. If what I suspect in Cygwin a Textmode mount means: produce text files with CRLF and a Binmode mount means: produce text files with LF then this is somewhat confusing since both modes are actually only concerned with text files. The reason that they are called Textmode and Binmode nevertheless I think is because of when you read a file and want to convert a text file to a standard line representation with only a single LF then you don't need to convert files with only LF. Not converting is also precisely what you should do with binary files, hence binary mode. I would like to make two points: 1. The User's Guide suggests that whether a command opens a file in binary or text mode can (should?) depend on the command: ..., all programs using lines as records (such as bash, make, sed ...) would open files (and change the mode of their standard input and output) as text. (Please note that this should include diff as well since that is line oriented as well.) Or can depend on environment: Most other programs (such as cat, cmp, tr) use the default mode. This environment includes: Textmode or Binmode mount. Environment variable: CYGWIN. However all of this overlooks the fact that whether a file should be opened in text or binary mode depends primarily on the file: If it is binary conversions should never take place! If it is a text file then conversion may take place. 2. Note that for text files one could always do a conversion from CRLF to LF on reading independent of the mode. (Text files with only LF are simply left invariant.) (All this is not to imply that it is easy to distinguish a text and a binary file, nor that it is always unreasonable to have a command treat all of its input as text.) diff. All files compared by diff should be subject to the same conversion. This is clearly violated by diff 2.8.7. Please note as I said before that for text files one can always perform a CRLF to LF conversion on reading. This should make it more convenient to compare UNIX and Windows native files e.g. A consequence is that if a text file and a binary file are compared that one should not apply any conversions. (But because comparing text and binary files seems not very useful anyway it probably won't make much difference if conversions are made.) One may want to have a flag for a truly binary diff. If I read in the User's Guide the closest I can get to what you said is in the paragraph: The default Cygwin behavior: a. If the file appears to reside on a file system that is mounted (i.e. if its pathname starts with a directory displayed by mount), then the default is specified by the mount flag. If the file is a symbolic link, the mode of the target file system applies. If I apply this to my system then I ran my test on my D: drive. The only cygwin mount on that drive is: d: on /cygdrive/d type system (textmode,noumount) Therefor in my opinion according to the User's Guide all files on my d: drive should have been opened by diff in text mode, which as we saw is currently not the case. On Fri, 4 Mar 2005, Igor Pechtchanski wrote: On Fri, 4 Mar 2005, Brian Dessent wrote: I cannot reproduce this, either from a bash prompt or from cmd using your .bat file: I can reproduce this (even under bash). All you need is a textmode mount and files with
Bug cat 5.2.1. No \ supported
When I executed the following command it failed: cat ..\..\diff\separateDirDiffs20050304\*.bat cat: diffseparateDirDiffs20050304*.bat: No such file or directory Replacing \ by / made it work. This violates the statements in the User's Guide that both separators will work. Output of: cat --version cat (coreutils) 5.2.1 Written by Torbjorn Granlund and Richard M. Stallman. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Cygwin Configuration Diagnostics Current System Time: Sat Mar 05 10:34:40 2005 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Program Files\Common Files\Adaptec Shared\System E:\cygwin\usr\local\bin E:\cygwin\usr\bin E:\cygwin\bin E:\cygwin\usr\X11R6\bin D:\Program Files\rksupport D:\Program Files\Subversion\bin E:\Borland\BCC55\Bin D:\Program Files\7-Zip D:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin D:\Program Files\Microsoft Visual Studio\Common\Tools D:\Program Files\Microsoft Visual Studio\VC98\bin D:\uts . Output from E:\cygwin\bin\id.exe (nontsec) UID: 1000(-) GID: 513(None) 513(None) Output from E:\cygwin\bin\id.exe (ntsec) UID: 1000(-)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT Path = `C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program Files\Common Files\Adaptec Shared\System;E:\cygwin\usr\local\bin;E:\cygwin\usr\bin;E:\cygwin\bin;E:\cygwin\usr\X11R6\bin;D:\Program Files\rksupport;D:\Program Files\Subversion\bin;E:\Borland\BCC55\Bin;D:\Program Files\7-Zip;D:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;D:\Program Files\Microsoft Visual Studio\Common\Tools;D:\Program Files\Microsoft Visual Studio\VC98\bin;D:\uts;' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\-\Application Data' APR_ICONV_PATH = `D:\Program Files\Subversion\iconv' CLASSPATH = `C:\Program Files\Java\j2re1.4.1_03\lib\ext\QTJava.zip' CommonProgramFiles = `C:\Program Files\Common Files' COMPUTERNAME = `LAMPION' ComSpec = `C:\WINNT\system32\cmd.exe' DIRCMD = `/ogn' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\-' include = `D:\Program Files\Microsoft Visual Studio\VC98\atl\include;D:\Program Files\Microsoft Visual Studio\VC98\mfc\include;D:\Program Files\Microsoft Visual Studio\VC98\include' lib = `D:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;D:\Program Files\Microsoft Visual Studio\VC98\lib' LOGONSERVER = `\\LAMPION' MSDevDir = `D:\Program Files\Microsoft Visual Studio\Common\MSDev98' NTRESKIT = `D:\Program Files\rksupport' NUMBER_OF_PROCESSORS = `2' OS = `Windows_NT' Os2LibPath = `C:\WINNT\system32\os2\dll;' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0501' ProgramFiles = `C:\Program Files' PROMPT = `$P$+$G' QTJAVA = `C:\Program Files\Java\j2re1.4.1_03\lib\ext\QTJava.zip' SystemDrive = `C:' SystemRoot = `C:\WINNT' TEMP = `C:\DOCUME~1\-\LOCALS~1\Temp' TMP = `C:\DOCUME~1\-\LOCALS~1\Temp' tvdumpflags = `10' USERDOMAIN = `LAMPION' USERNAME = `-' USERPROFILE = `C:\Documents and Settings\-' windir = `C:\WINNT' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0020 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `E:\cygwin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `E:\cygwin/bin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `E:\cygwin/lib' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `E:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd FAT32 4086Mb 80% CPUN SYSTEM d: hd FAT32 8079Mb 89% CPUN PROGRAMS e: hd FAT3224658Mb 17% CPUN DATA f: cd N/A
Bug diff 2.8.7: Separate dir
Noticed that when diff is run with two differing files, one with and one without a directory specifier: diff a someDir\b then all lines are reported as different. Whereas when both have a directory specifier: diff .\a someDir\b output is normal. (Filenames, argument order or using -d seem irrelevant. Using / instead of \ makes output normal also: diff a someDir/b output is normal. Similarly when comparing a and someDir\a as: diff a someDir output is also normal. ) As an illustration I have provide a sample batch file. (It creates up to two directories and two files): ** @echo off setlocal set bugdir=showSeparateDirDiffBug if not exist %bugdir%\ md %bugdir% pushd %bugdir% set subdir=adir if not exist %subdir%\ md %subdir% set file1=a set file2=%subdir%\%file1% echo a%file1% echo a%file1% echo a%file1% echo a%file2% echo b%file2% echo a%file2% echo This batch file: %0 echo. diff --version rem Bug rem same: diff -d %file1% %file2% diff %file1% %file2% rem OK diff .\%file1% %file2% popd endlocal ** I expect this to run as is on a not too old version of the Windows NT line of OS. On my Windows 2000 system this produces the following output: * This batch file: separateDirDiffBug.bat diff (GNU diffutils) 2.8.7 Written by Paul Eggert, Mike Haertel, David Hayes, Richard Stallman, and Len Tower. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 1,3c1,3 a a a --- a b a 2c2 a --- b * Since the relevant factor seems to be a directory specifier this bug is probably Cygwin specific. (Btw I used a batch file so that the only Cygwin functionality used would be directly bug related for clarity. If there is a different format that would make it easier to add to the testscripts that are used for the automatic testing of these utilities please provide me with an example so I can model future similar bugreports along those lines.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
