This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [APPS] ping python maintainer (and others) - Launching cygwin apps from cmd.exe vs. softlinks in /bin


On Mon, 20 Sep 2004, Dave Korn wrote:

>   I thought this topic ought to be on the -apps list, but the description
> does say...
>
> "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 -> python2.3.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.

Alternatively, you could Google for "vi.bat site:cygwin.com" and apply the
same technique to python.

> 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
> starters.
>
>   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?

Some more randomly-ordered points:

a) the cluster size can be as large as 32k, which means that even a
symlink takes up that much space.

b) FWIW, if the symlink is set up in a postinstall script instead of the
tarball, it'll be a new style 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>.

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]