This is the mail archive of the
mailing list for the Cygwin project.
[APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin
- From: "Dave Korn" <dk at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Mon, 20 Sep 2004 16:09:50 +0100
- Subject: [APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin
I thought this topic ought to be on the -apps list, but the description
"It is not (with one exception) for bug reports, "it would be nice", or "how
do I" type of musings."
... so I'm mentioning this here instead.
It's quite a common idiom in cygwin packages (based on longstanding unix
tradition) to have an executable that has the version number appended to it,
and then use a soft-link to provide an unadorned executable, e.g.:
dk@mace /bin> ls -la python*
lrwxrwxrwx 1 dk Users 13 Jan 5 2004 python.exe ->
-rwxr-x---+ 1 dk Users 4608 Dec 30 2003 python2.3.exe
Now, in this particular case "python.exe" is a cygwin old-style softlink
rather than a windoze .lnk-style shortcut. This means that it can't be
invoked from cmd.exe; because a cygwin old-style softlink is basically a
text file, cmd.exe notices that it has no PE/MZ header, but since it's got a
.exe extension, cmd.exe thinks it has to be _some_ kind of executable, so it
guesses the only thing left - that it's an old 16-bit MSDOS .com-type
executable - and invokes NTVDM, which loads the file into memory and starts
happily executing ASCII bytes as opcodes (or at any rate, happily until it
gpfaults within the first few bytes).
It's a shame, because most normal cygwin apps can be invoked either from
bash or from cmd. And it's a shame in particular for Python, because the
cygwin and win32-native versions are very close to functionally
interchangeable, and if it wasn't for this slight hiccup they could be used
that way (with only a little attention to not using OS-specific features in
your python scripts).
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.
Using a new-style symlink fails in several interesting ways:
1) Well, there's the .lnk extension to take into account, which is a minor
nuisance because you can't invoke it with just 'python.exe'.
2) Also, "ln -s" sets utterly wrong ACLs on the link it creates, such that I
have no "read and execute" permission. (I think this is a genuine bug, but
I'll start a separate thread for it once I've confirmed that.)
3) So after I modify the ACLs, and invoke it by typing
"shortcutname.exe.lnk" at a cmd.exe shell, something very bizarre happens:
it forks off from the shell, and both cmd.exe and the python exe are running
simultaneously, connected to the same stdin and fighting each other for
chars from my command lines. [ Can I refer to this as "a terrible forking
bug" without getting banned from the list? :-O ]
Now, I know that using a hardlink has the effect on FAT filesystems of
simply duplicating the file, and so this might not be a desirable or
possible solution to adopt in the majority of cases. I'm not sure how
compatible it would or wouldn't be with the cygwin packaging scheme, for
But the python executable is a special case, because it's tiny: 4608
bytes, because all the actual functionality is in a .dll, and the .exe
simply has to load the .dll and call out to it. So in this particular case,
(and any similar ones, such as zsh, perl, and conceivably even tclsh,
although at 16kb the waste/redundancy starts to become more worth
considering) it might be entirely reasonable to simply provide two identical
duplicate .exes in the package, mightn't it?
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html