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: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN


Based on the emails under this thread and other items I found, it seems that anomalies
handling program suffixes within CYGWIN are not new.  It has been proposed that the 
relevant code be re-thought.  I suggest that any rethink consider PATHEXT support.

It may be of no interest for CYGWIN users of pure Posix applications and tools never intended 
to use, or be used by, Win32 programs as has been pointed out within this thread.  Even then,
Windows underpins CYGWIN so its rules percolate up.  

For users who wish to exploit the power of CYGWIN tools and shells to control 
and supplement Win32 tools, to control and configure Windows and Windows subsystems, 
and extensive corporate applications under Windows,  PATHEXT (plus the file associations 
that determine how to invoke the handler for a given suffix) is a part of the bridge.
In a sense, in this case Windows rules, conventions, and expectations percolate down.

CYGWIN addressing Windows program invocation comprehensively once and for all
might help rationalise things and reduce the anomalous end cases that seem to 
crop up while satisfying the needs  of hybrid CYGWIN/Win32 users.

As a novice CYGWIN user, It is quite possible that I misunderstand CYGWIN and that inter-operation 
with Win32 environments is not an objective in which case perhaps somebody can set me straight 
and recommend an alternative.  It could very well be that, as one response to me on this thread 
alluded, CYGWIN's role is to provide the equivalent of an isolated POSIX VM under Windows 
without the VM. Such isolation pretty much excludes Windows developers and integrators and 
begs the question as to why host all this POSIX infrastructure within Windows in the first place
especially now that VM support is pervasive and efficient?

I expect that many CYGWIN users in fact blend CYGWIN and Win32 tools to build solutions.

As a novice CYGWIN user, I was first struck by the variety of offshoots from CYGWIN. 
Presumably, these offshoots satisfy some un-met needs but must result in dilution of talent and effort.
Maybe I should be looking at one of these but my first cursory looks showed that some
common Unix utilities that I find useful were missing but are in CYGWIN which is why I wound up here.

I really hope to not have offended anybody.

Michel



--
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


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