3.3.3: possible DLL breakage with network mounted drives running make
Hey Folks, Trying to track down why our builds started failing after upgrading to cygwin 3.3.3. Narrowed it down to a change in how make (gmake) is invoked with a specified directory to execute in and that directory is a network drive in windows (10, 21H2). simple Makefile attached and below: all: @echo CURDIR=$(CURDIR) my drive is mounted as "M:" in both tests on cygwin 3.3.3 dilkiel@fal-pc-100 /cygdrive/m $ make -C ./ -f Makefile make: Entering directory '//192.168.51.103/views' CURDIR=//192.168.51.103/views make: Leaving directory '//192.168.51.103/views' I used the '-C' option so you could more easily see the problem. on older cygwin (2.11.2) dilkiel@CA632444 /cygdrive/m $ make -C ./ -f Makefile make: Entering directory '/cygdrive/m' CURDIR=/cygdrive/m make: Leaving directory '/cygdrive/m' Problem: The '//192.168.51.103/views' version of a filename isn't going to work for a lot of parts of make that are expecting either a windows 'm:/' or cygwin style '/cygdrive/m' directory path. This directory get used with make targets and that path won't convert to windows format properly with cygpath and is unusable passed to most windows programs. BTW, even cygcheck didn't like being run from this directory. dilkiel@fal-pc-100 /cygdrive/m $ cygcheck -s -v -r > cygcheck.out '\\192.168.51.103\views' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. '\\192.168.51.103\views' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. '\\192.168.51.103\views' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. I couldn't find anything in the last few months of the mailing list so perhaps I have something odd in my enviro? (identical enviro on both machines, BTW, they are clones of each other). NOTE: works correctly on physically mounted drives. Can anyone help? thanks, -lee all: @echo CURDIR=$(CURDIR) Cygwin Configuration Diagnostics Current System Time: Fri Dec 03 19:07:03 2021 Windows 10 Professional Ver 10.0 Build 19044 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Program Files (x86)\Common Files\Oracle\Java\javapath C:\Perl64\site\bin C:\Perl64\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\IBM\RationalSDLC\clearcase\RemoteClient\cteapis C:\Program Files\Mitel\AutoSDK\CommonDlls C:\Program Files (x86)\Mitel\AutoSDK\VirtuaFone C:\Program Files (x86)\Mitel\AutoSDK\CommonDlls C:\Program Files\Microsoft SQL Server\110\Tools\Binn C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0 C:\WINDOWS\System32\OpenSSH C:\Go\bin C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR C:\Program Files\Docker\Docker\resources\bin C:\ProgramData\DockerDesktop\version-bin C:\Users\dilkiel\AppData\Local\Programs\Python\Python38-32\Scripts C:\Users\dilkiel\AppData\Local\Programs\Python\Python38-32 C:\Users\dilkiel\AppData\Local\Microsoft\WindowsApps C:\Users\dilkiel\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin C:\Users\dilkiel\AppData\Local\Programs\Microsoft VS Code\bin C:\Users\dilkiel\go\bin Output from C:\cygwin64\bin\id.exe UID: 197609(dilkiel) GID: 197121(None) 197121(None) 197611(docker-users) 559(Performance Log Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 401408(Medium Mandatory Level) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'dilkiel' PWD = '/cygdrive/m' HOME = '/home/dilkiel' USERDOMAIN = 'FAL-PC-100' OS = 'Windows_NT' MACRIUM_1785_PASSWORD = '1' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' PROCESSOR_LEVEL = '6' PSModulePath = ';C:\Users\dilkiel\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\PowerShell' CommonProgramW6432 = 'C:\Program Files\Common Files' tug_log_dir = 'b:/tmp' MACRIUM_1784_DIRECTORY = 'd:\MacriumBackupWin10\' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' tug_icpside_bind4 = '10.39.164.100' TZ = 'America/New_York' MACRIUM_1784_METHOD7 = '1' MACRIUM_1784_METHOD6 = '1' MACRIUM_1784_METHOD5 = '2' MACRIUM_1784_METHOD4 = '1' MACRIUM_1784_METHOD3 = '1' MACRIUM_1784_METHOD2 = '1' MACRIUM_1784_METHOD1 = '0' HOSTNAME = 'fal-pc-100' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/build' MACRIUM_1785_CURRENT_INCREMENT = '7' MACRIUM_PREFIX = 'MACRIUM_1785' USERNAME = 'dilkiel' IDIR_TEMPDIR = 'd:\tmp' LOGONSERVER = '\\FAL-PC-100' PR
Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
On 2/24/2017 9:43 AM, Eric Blake wrote: On 02/23/2017 10:57 PM, Steven Penny wrote: Or more likely, many people likely have pre-existing scripts wrongly written as #!/bin/sh but which use bash-ism rather than portable POSIX-specified shell However, I think it is worth the trouble. If you'd like, I can post experimental versions of both bash and dash, which MUST be upgraded (or downgraded) in lockstep, where I move /bin/sh over to the dash package (do it wrong, and you could be left with no /bin/sh at all, which is not a good idea - although maybe I can use some postinstall scripts so that at least the upgrade side tries to play nice even when someone only does a partial upgrade). If people will then test with those experimental versions installed, and report breakage, we could get a feel for how many scripts installed by default are broken. But we are severely limited in volunteer manpower compared to Debian, and I suspect that 1) there won't be enough testers (we won't know the real impact until it is no longer experimental, but that is too late), and 2) even if testers are diligent, we will be unable to patch all the fallout in any sort of timely manner. Are you really prepared to force the Cygwin community through that much growing pain? I agree that /bin/sh as dash is much faster at executing configure scripts. But configure scripts aren't the only scripts in the wild. We do have checkbashisms ported to Cygwin, and that can help, but it is not a panacea. If dash doesn't support all the features of bash (which is incorrectly assumed in some cases for sh), aren't you just asking for trouble by breaking things? -lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Console buffer width always 1 column less than setting
On 2/7/2017 9:40 AM, cyg Simple wrote: On 2/7/2017 9:23 AM, Lee Dilkie wrote: Cyg, I understand list etiquette but I'm referring to *human* etiquette. Steve asked for help, got help but rather than acknowledge it (and add a note at the bottom to *politely* tell Vince that he should find a way to sanitize email addresses out of his replies), he just jumps aggressively on the quoting issue (and confused things in the process because he, I assume, meant to say "email addresses" instead of "email directly", which doesn't parse well in english). So I stand by my observation, Steve acted like a dork here. Such name calling isn't taken well regardless of where it is used. Please refrain from expressing such personal beliefs about anyone or anything to this and any other list you may subscribe to. The English language is an ever evolving and fluid language and often a redefinition occurs due to the human nature of being lazy. I completely understood Steven meant "email addresses" with his shortened form to "email" and would even use it the way Steven did myself. Indeed, English is an ever evolving language and I never called Steve any names at all. The language can be very precise as well. You may well have understood what he meant, but those of us who have only been speaking the language for 55 years, myself, didn't. I was quite confused by what he meant and it took me a few minutes to figure it out. Normally I wouldn't have bothered but I was really curious as to what prompted his vitriolic (in my opinion) response. -lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Console buffer width always 1 column less than setting
On 2/7/2017 9:11 AM, cyg Simple wrote: On 2/6/2017 12:43 PM, Lee Dilkie wrote: On 2/5/2017 3:59 PM, Steven Penny wrote: On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote: On Feb 5, 2017, at 1:53 PM, Steven Penny wrote: Please fix your email client. You should not be quoting people’s email directly. that's just silly. Anyone with access to this public list has your email address when you posted. The guy was just trying to help you with your issue, and you come across as a dork. Lee, this and many such lists expects the etiquette that Steven has requested of Vince. Elide the email address of the quoted person. Many clients offers to do this for you automatically, if you can't with yours you should find one that does. Cyg, I understand list etiquette but I'm referring to *human* etiquette. Steve asked for help, got help but rather than acknowledge it (and add a note at the bottom to *politely* tell Vince that he should find a way to sanitize email addresses out of his replies), he just jumps aggressively on the quoting issue (and confused things in the process because he, I assume, meant to say "email addresses" instead of "email directly", which doesn't parse well in english). So I stand by my observation, Steve acted like a dork here. -lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Console buffer width always 1 column less than setting
On 2/5/2017 3:59 PM, Steven Penny wrote: On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote: On Feb 5, 2017, at 1:53 PM, Steven Penny wrote: Please fix your email client. You should not be quoting people’s email directly. that's just silly. Anyone with access to this public list has your email address when you posted. The guy was just trying to help you with your issue, and you come across as a dork. -lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installer names not meaningful enough
On 12/1/2016 5:51 AM, Roberto Ríos Gallardo wrote: Please give the installers more meaningful names. In particular, make sure "cygwin" is part of it. "setup-x86_64.exe" is not very obvious. A version number would be nice too. I'd agree that adding "cygwin" to the setup program would be nice but it's certainly not the windows "way", lots of programs use just "setup.exe". Versioning can't be added to the file name because the setup program itself isn't versioned, or at least isn't the same version as the cygwin you are installing... the cygwin version come from the servers... -lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygpath -w and .exe magic
On 8/26/2016 9:08 AM, Nellis, Kenneth wrote: Dear Cygwin Community, $ ls -l total 60 -rwxr-x--- 1 knellis Domain Users 60927 Aug 26 08:57 hello.exe $ ./hello Hello, world! $ cygpath -w hello hello $ The purpose of cygpath -w, it seems to me, is to provide to Windows a valid path given a Posix path. Given executable file foo.exe, which Cygwin allows to be referenced simply as foo, should not: cygpath -w foo return: foo.exe instead of: foo ? Passing foo to a Windows application will certainly be a problem. I recognize this might be considered a change of scope for the program, but I think the tool should do the .exe magic rather than pass off this responsibility to the user. Food for thought. and break everyone who has existing code to take care of this? -- 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: FD_SETSIZE and sizeof(fd_set)
On 6/23/2016 6:54 AM, Steven Bardwell wrote:
Here is a "program" that shows the issue I am worried about. It is so simple
that I must be overlooking something really obvious:
#include
#undef FD_SETSIZE
#define FD_SETSIZE 256
#include
#include
main()
{
fd_set rfds;
fprintf(stdout, "FD_SETSIZE=%d\n", FD_SETSIZE);
fprintf(stdout, "sizeof(fd_set)=%d\n", sizeof(fd_set));
}
Steve Bardwell
I don't know if this is still the case, but when I looked into this years ago I
found that it was not possible to change the size of the fd set in linux, it's
fixed at 1024 (generally), unless you rebuild the kernel.
Secondly, in the windows api, their version of an fd_set is more like a poll()
implementation, you can fake out any size you want since the size of the array
is the first entry.
I can't speak for the cygwin implementations, but if they offer poll() or,
better, epoll(), use those.
-lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how do I report a bug in cygpath
Christopher Faylor wrote: > FWIW, it is entirely possible that if you had submitted the requested > cygcheck output the problem would have been more obvious. > > -- > > I don't doubt that for a minute. In fact, I went and gathered all the cygcheck output and was composing the email when I came across Corinna's response. Next time... I'll do it by the book ;) Thanks folks, -lee -- 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: how do I report a bug in cygpath
Corinna Vinschen wrote: > On Nov 10 16:06, Lee Dilkie wrote: > >> Hi folks, >> >> If this isn't the list, or the method, how would one go about reporting >> a bug in the cygpath utility. It is reporting an absolute path for >> windows style in all invocations and ignoring the absence of -a. >> >> $ cygpath -w foo >> C:\foo >> >> $ cygpath -wa foo >> C:\foo >> >> $ cygpath -u foo >> foo >> >> $ cygpath -ua foo >> /cygdrive/c//foo >> > > I could reproduce the problem. I applied a patch to CVS. > > > Thanks for the report, > Corinna > Thank you for the fix. -lee -- 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: how do I report a bug in cygpath
Christopher Faylor wrote: > On Mon, Nov 10, 2008 at 11:07:23PM -0500, Lee Dilkie wrote: > >> Christopher Faylor wrote: >> >>> On Mon, Nov 10, 2008 at 06:33:03PM -0500, Lee Dilkie wrote: >>> >>> >>>> Larry Hall (Cygwin) wrote: >>>> >>>> Thanks for the reply Larry. >>>> >>>> >>>>>> It is reporting an absolute path for >>>>>> windows style in all invocations and ignoring the absence of -a. >>>>>> >>>>>> $ cygpath -w foo >>>>>> C:\foo >>>>>> >>>>>> $ cygpath -wa foo >>>>>> C:\foo >>>>>> >>>>>> $ cygpath -u foo >>>>>> foo >>>>>> >>>>>> $ cygpath -ua foo >>>>>> /cygdrive/c//foo >>>>>> >>>>>> >>>> >>> Sorry but this WJFFM in cygwin-1.7.0-31 although the double // in the >>> -ua case is annoying. >>> >>> >> Sorry, but where is the manual or documentation for 1.7.? >> > > 1.7.0 hasn't been released. It's in a "If you have to ask you probably > shouldn't be using it" state. > > cygpath --help > > Will provide you with accurate help. > Thanks, but I guess I was looking for more along the lines of change logs or something. You know, a headsup along the lines of the faw for 1.5. But as you say, it's still in development. > >> Is it intentional that the output of cygpath would change in such a >> non-backwards-compatible way? Showing only absolute paths in windows >> broke my makefile scripts. >> > > Please don't jump to conclusions. No one has said anything about > changing the output of cygpath Sorry, I misunderstood your "WJFFM in cygwin 1.7.0-31" comment. I thought you meant that this output was intentional. So that now leaves us with my my cygwin 1.7 install produces the same output for "cygpath -m foo" and "cygpath -ma foo". I have tried this on two machines, with the same results. $ cygpath foo foo $ cygpath -m foo C:/Documents and Settings/v-leed/foo $ cygpath -ma foo C:/Documents and Settings/v-leed/foo $ And while I'm at it... Dumb question. How do I find out what version of cygwin is installed? You're comment about 1.7.0-31 has me curious. > . > > If you read > > http://cygwin.com/problems.html > > that is one of the subtle points that is trying to be made. > I have read that page in the past, and again just now. I'm not seeing the subtle point... 'course it could be *real* subtle... ;) > Once again: http://cygwin.com/acronyms/#WJFFM > > >>> You asked how to report problems. The answer to your question is at the >>> bottom of every message to the cygwin mailing list: >>> >>> >>>> Problem reports: http://cygwin.com/problems.html >>>> > > cgf > > -- > 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/ > -- 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: how do I report a bug in cygpath
Christopher Faylor wrote: > On Mon, Nov 10, 2008 at 06:33:03PM -0500, Lee Dilkie wrote: > >> Larry Hall (Cygwin) wrote: >> >> Thanks for the reply Larry. >> >>>> It is reporting an absolute path for >>>> windows style in all invocations and ignoring the absence of -a. >>>> >>>> $ cygpath -w foo >>>> C:\foo >>>> >>>> $ cygpath -wa foo >>>> C:\foo >>>> >>>> $ cygpath -u foo >>>> foo >>>> >>>> $ cygpath -ua foo >>>> /cygdrive/c//foo >>>> >>> WJFFM. What does 'cygpath --version' report for you? Mine is 1.42.4.1. >>> Perhaps you're out of date? >>> >>> >> $ cygpath --version >> cygpath (cygwin) 1.51 >> Path Conversion Utility >> Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, >> 2007, 2008 Red Hat, Inc. >> Compiled on Oct 30 2008 >> >> I forgot to mention this is a cygwin 1.7 issue, my 1.5 version worked fine. >> > > Sorry but this WJFFM in cygwin-1.7.0-31 although the double // in the > -ua case is annoying. > Sorry, but where is the manual or documentation for 1.7.? Is it intentional that the output of cygpath would change in such a non-backwards-compatible way? Showing only absolute paths in windows broke my makefile scripts. > You asked how to report problems. The answer to your question is at the > bottom of every message to the cygwin mailing list: > > >> Problem reports: http://cygwin.com/problems.html >> > > cgf > > -- > 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/ > -- 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: how do I report a bug in cygpath
Larry Hall (Cygwin) wrote: Thanks for the reply Larry. >> It is reporting an absolute path for >> windows style in all invocations and ignoring the absence of -a. >> >> $ cygpath -w foo >> C:\foo >> >> $ cygpath -wa foo >> C:\foo >> >> $ cygpath -u foo >> foo >> >> $ cygpath -ua foo >> /cygdrive/c//foo > > WJFFM. What does 'cygpath --version' report for you? Mine is 1.42.4.1. > Perhaps you're out of date? > $ cygpath --version cygpath (cygwin) 1.51 Path Conversion Utility Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc. Compiled on Oct 30 2008 I forgot to mention this is a cygwin 1.7 issue, my 1.5 version worked fine. regards, -lee -- 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/
how do I report a bug in cygpath
Hi folks, If this isn't the list, or the method, how would one go about reporting a bug in the cygpath utility. It is reporting an absolute path for windows style in all invocations and ignoring the absence of -a. $ cygpath -w foo C:\foo $ cygpath -wa foo C:\foo $ cygpath -u foo foo $ cygpath -ua foo /cygdrive/c//foo -lee -- 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 -m output incorrect on cygwin 1.7
Hi Folks, I run the setup-1.7 and upgraded my 1.5 version to try it out and I came across this. cygwin 1.5 [EMAIL PROTECTED]: /cygdrive/g/dilkiel_Tug_parallel_1/SmallApps/TUG $ cygpath -m foo foo cygwin 1.7 [EMAIL PROTECTED] ~/views/dilkiel_Tug_parallel_1/SmallApps/TUG $ cygpath -m foo C:/views/dilkiel_Tug_parallel_1/SmallApps/TUG/foo notice that the 1.7 behaviour is to prepend the current path, which is a cnage from the previous version. (and I don't think it's what one would expect). -lee -- 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: cd not following windows shortcuts
And on top of that (top posting too), even windows cmd console won't let you follow .lnk files... They are files, not symlinks. Only explorer know how to navigate them. -lee Brian Dessent wrote: Gustavo Seabra wrote: Right, it isn't a directory. But shouldn't Cygwin convert the path and follow it just the same? Is there something wrong with the behavior I'm seeing? For one thing, the .lnk must have the R attribute set in order for Cygwin to even consider it a symlink and not a regular file, and normally Explorer does not set the R attribute. And of course a .lnk created with Explorer will not have the POSIX path set in the 'description' field, meaning that it can only point to an absolute Win32 path unless you hand edit the field. Moreover the symlink reading code in Cygwin does not contain a full parser for the shortcut file format (which AFAIK is some kind of undocumented memory dump of a shell COM object, which can take on many forms e.g. a shortcut to Control Panel), only enough to read the specific format that Cygwin creates, so it wouldn't surprise me if it was possible to create all kinds of shortcuts in Explorer that Cygwin can't parse. You might be lucky and simply setting +R might suffice, I have no idea. But if it doesn't, realize that the intent of the feature was for Cygwin-created symlinks to also work in Explorer as a bonus, not necessarily the other way around. Brian -- 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/ -- 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: Question about link.exe?
I found that setting the complier and linker (all the tools, actually) to the full path is the most reliable means to ensure the correct executables are picked up. ie. CC = full_path_to_ds_8_bin/cl.exe LINK = full_path_to_ds_8_bin/link.exe you can use the registered environment variables for DS to build the full path up. (can't remember the name right now, I'm at home). -lee Chris Howell wrote: I am running on Vista, and what I am doing is I open up a Dev Studio 2008 command shell. From that command shell I launch cygwin/bash... Things like cl.exe are inherited from the first shell I've opened in the bash environment. What I want is link to be the path that is found under my BIN directory of my DevStudio install. However possibily because they're the same name when I query link, or try and use it to make a dll. Bash thinks I am using link to make a symbolic link as opposed to a dll. Any suggestions or help would be appreciated. Cheers Chris Howell Software Engineer the PYXIS innovation inc Kingston Ontario, w: www.pyxisinnovation.com p: 613-389-3430 -- 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/ -- 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/
