<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>background:<BR>
<BR>Windows has $PATH and $PATHEXT.<BR>$PATHEXT is used by the usual command line -- cmd -- to help find "executables".<BR>
<BR>On one of my systems:<BR>
C:\>set path<BR>Path=C:\Python25\;C:\Tcl\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Perl\bin;c:\ruby\bi<BR>n;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Quick<BR>Time\QTSystem\<BR>PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.RB;.RBW;.tcl;.py;.pyw<BR>
<BR>(oops, I'll go clean it up..)<BR>
<BR>"Executables" are not just .exes.<BR>
<BR>The commands ftype and assoc combine to enable running "anything", based on extension.<BR>
<BR>For example:<BR>
<BR>C:\>assoc .exe<BR>.exe=exefile<BR>
<BR>C:\>ftype exefile<BR>exefile="%1" %*<BR>
<BR>C:\>assoc .js<BR>.js=JSFile<BR>
<BR>C:\>assoc .vbs<BR>.vbs=VBSFile<BR>
<BR>C:\>assoc .py<BR>.py=Python.File<BR>
<BR>C:\>assoc .tcl<BR>.tcl=ActiveTclScript<BR>
<BR>C:\>ftype activetclscript<BR>activetclscript="C:\Tcl\bin\wish85.exe" "%1" %*<BR>
<BR>C:\>ftype python.file<BR>python.file="C:\Python25\python.exe" "%1" %*<BR>
<BR>C:\>ftype jsfile<BR>jsfile=%SystemRoot%\System32\WScript.exe "%1" %*<BR>
<BR>C:\>ftype vbsfile<BR>vbsfile=%SystemRoot%\System32\WScript.exe "%1" %*<BR>
<BR>If you ignore the need for executables to have extensions, this provides much of<BR>the feature of Unix where any file is executable, possibly via a specified interpreter.<BR>It is better and worse.<BR>It is worse in that extensions are needed.<BR>It is better in that files don't have to give the possibly system-specific path<BR>to their interpreter.<BR>It is worse in that files cannot give the path to the interpreter.<BR>
It is worse in that it is a feature of the command line interpreter, instead of lower layers (kernel) as I believe on Unix.<BR>
<BR>Now, I have a small problem of convenience.<BR>And you all MIGHT have a "problem" of "What is Posix?"<BR>
My c:\cm3 contains a mix of NT386 and NT386GNU files.<BR> c:\cm3\pkg\cm3\NT386\cm3.exe <BR> c:\cm3\pkg\cm3\NT386GNU\cm3.exe <BR>
ok<BR>
but then what is c:\cm3\bin\cm3.exe ?<BR>
<BR>Currently it is the most recently shipped file.<BR>
<BR>For the case of .dlls, I have enabled "colocation" by changing NT386GNU .dlls to end in .so.<BR>So I have:<BR>
c:\cm3\bin\m3.dll <BR> c:\cm3\bin\m3.so <BR>
<BR>Probably this should be libm3.so and probably will be some day.<BR>
<BR>I would a system whereby somehow the two targets can coexist better.<BR>
<BR>Perhaps I should just suck it up and have c:\cm3\nt386 and c:\cm3\nt386gnu.<BR>Perhaps.<BR>
<BR>
Quick experimentation shows that you can have an "empty" extension.<BR>
<BR> set PATHEXT=.;%PATHEXT% <BR> cd \cygwin\bin<BR> copy ls.exe foo <BR> .\foo <BR>
<BR> => It works. <BR>
<BR>You don't actually have to do anything with assoc and ftype. Oops. I didn't have to bring that up.<BR>
<BR>The order of %PATHEXT% varies.<BR>
<BR>So, the proposal is, in the interest of killing two birds with one stone, neither of which<BR>was necessarily even alive at the start, is that NT386GNU use no extension for .exes.<BR>
<BR> \cm3\bin\cm3 is NT386GNU <BR> \cm3\bin\cm3.exe is NT386 (or NT386MINGNU) <BR>
<BR>I started thinking about this partly because "Services for Unix" makes .exes with no extension.<BR>And because I suspect the handling here in Cygwin is hacky.<BR>There is various code such that if someone looks for "foo", they might find "foo.exe" instead.<BR>
<BR>Upsides:<BR> "It works".<BR>
<BR>
Downsides:<BR> "foo" used to resolve via %PATH% + %PATHEXT% search..and it still does, but putting<BR> . at the start will find foo where foo.exe was more common.<BR>
<BR> It is not general. This scheme does not enable any other "multi arch" install.<BR>
<BR> Alternate proposal with a question: <BR> How should "multi arch" installs be achieved? <BR> Probably via making \cm3\bin\foo on Posix and \cm3\bin\foo.cmd on NT that somehow <BR> sniffs its environment, perhaps with uname, and then runs \cm3\pkg\foo\?\foo (or foo.exe) <BR>
<BR> Upsides: <BR> It works, at least for executables. <BR> It is more general than my previous suggestion. <BR>
<BR>
Downsides: <BR> Extra processes created. <BR> What about .dlls/.sos? <BR>
<BR> Maybe nobody cares? <BR>
<BR> I find the idea of one unified file system/archive that works on "everything" fairly compelling. <BR> Yeah, it's big. Yeah, it's slower to install. But it means one download can be had <BR> independently of platform. <BR>
<BR>Maybe simply \cm3\platform instead of \cm3?<BR>
<BR> upsides: <BR> it works <BR> is general <BR> no new mechisms invented! <BR> <BR> downsides: <BR> none? <BR> too boring? :) <BR> \cm3\platform\pkg\foo\platform is redundant. <BR> Less able to do "cross" scenarios that I'm using a lot lately, where NT386 and NT386GNU can build each other?<BR> Not clear. Probably just a matter of $PATH and $CM3_INSTALL not coinciding.<BR>
cm3 -ship could see if CM3_INSTALL ends in "\platform" and in that case not put in the second instance,<BR> but this possibly asking for trouble. Probably a bunch of code would have to learn about this.<BR>
<BR> Just live with the duplication of "platform", in the unusual situation of a "multi arch" file system? <BR>
<BR>
Maybe there is nothing to do here.<BR>
<BR>
The matter of what the file extension should be on NT386GNU perhaps is a different matter, left up to the hypothetical users of NT386GNU (not me).<BR>
"What is Posix?" Executables with no extension? Or don't care? Cygwin usually uses ".exe", but of course Cygwin bash allows running stuff with "shebang".<BR>
Microsoft/Interix "Services for Unix" puts no extension on executables. I found that a bit impressive, maybe worth striving for, and then surprisingly easy.<BR>
I am almost surprised Cygwin doesn't do this. I don't know if putting "." in $PATHEXT is any worse than adding \cygwin\bin to $PATH.<BR>
"If it is good enough for Cygwin, it is good enough for CM3/NT386GNU users?"<BR>
<BR>
I am not proposing extensionless executables for NT386. That would just be considered wierd.<BR>
However the "wrapper .cmd" files, maybe.<BR><BR>
- Jay<BR><BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>