This is the mail archive of the
mailing list for the Cygwin project.
RE: [APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Dave Korn <dk at artimi dot com>
- Cc: cygwin at cygwin dot com
- Date: Mon, 20 Sep 2004 13:09:51 -0400 (EDT)
- Subject: RE: [APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin
- References: <NUTMEGERq8GdHDIGX61000000bd@NUTMEG.CAM.ARTIMI.COM>
- Reply-to: cygwin at cygwin dot com
On Mon, 20 Sep 2004, Dave Korn wrote:
> > -----Original Message-----
> > From: Igor Pechtchanski
> > Sent: 20 September 2004 17:07
> > > Using a non-symbolic link works for me; "ln /bin/python2.3.exe
> > > /bin/cmd-invokable-python.exe" gets me something I can
> > invoke from either
> > > DOS/cmd or bash/sh.
> > Alternatively, you could Google for "vi.bat site:cygwin.com"
> > and apply the same technique to python.
> Fair enough, but what I really want is something that doesn't require my
> makefiles to have to discriminate between what kind of python exe is first
> in the path;
If you use just "python", and the .bat is first in the path, it'll be
> I want them to be equipotent, and I don't want to have to
> install things that aren't standard; I want a makefile that can be invoked
> from either cmd.exe or bash, that can run on a system that has either cygwin
> python or win32 python or both installed, that isn't sensitive to which one
> comes in which order in $PATH, and that doesn't require anything extra to be
> installed. But I guess I could always use a makefile rule to create
> python.bat in the objdir I'm building in.... hmm. That might have been a
> bit simpler than my current solution, which uses a fairly gross makefile
> hack to search $PATH and some default install locations for any instances of
> python.exe, then discards any which live in a ".../bin/.." subdir to try and
> eliminate the cygwin version!
You could also just create a python.bat in /bin, and cmd.exe will find
that, while Cygwin will use a symlink.
> > c) the code in spawn.cc currently treats any file with a .exe
> > extension specially, and passes it on to CreateProcess without looking
> > into it any more than that. It could, technically, check whether the
> > file is an old-style symlink, and do the right thing in that case --
> > as always, <http://cygwin.com/acronyms/#PTC>.
> LOL, I don't really think it's within my abilities to come up with a patch
> for spawn.cc that modifies the behaviour of cmd.exe.......
While CGF was obviously joking about the pty/tty "fix", my suggestion was
only half-humorous. Look in spawn.cc around line 442... FWIW, you won't
be fixing the behavior of cmd.exe, you'll be fixing the behavior of
Cygwin1.dll when a .exe program is invoked (before it's passed to Windows
via CreateProcess, i.e., the current action for .exe's and some others is
to *not* look inside the file to check whether it's a script or a
|\ _,,,---,,_ firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ email@example.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing." -- Dr. Jubal Harshaw
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html