Adding MSYS functionality to Cygwin

Алексей Павлов alexpux@gmail.com
Tue Jun 18 19:31:00 GMT 2013


2013/6/18 Warren Young <warren@etr-usa.com>:
> On 6/18/2013 12:40, Алексей Павлов wrote:
>>
>>
>> 1. The correct definition of executables belonging to Cygwin DLL.
>
>
> Can you give an example of what you mean here?
>
All cygwin applications depends on cygwin1.dll. We need to translate
arguments only for non-cygwin applications.

> This must be some kind of translation error, since executables never belong
> to DLLs.  The reverse is sometimes true, but mostly not.
>
>
>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>
> I don't see how Cygwin can reliably predict when and whether to do this.
> That is why it provides cygpath(1).  You, the user, use that tool when you
> know you need a translation done.
>
>
Win32 application doesn't know anything about cygwin paths and can't
use it. For example, you cannot do something like this on Cygwin:
 notepad /home/user/mydoc.txt
Also when you using autoconf utilities generated Makefile has Cygwin
paths and you cannot use it with native compiler.


>> 3. In MSYS mode Cygwin need to be very portable
>
>
> It would indeed be nice to have a portable Cygwin.  That is, one that could
> be run from a copied directory or USB key, without being formally installed.
> Such a thing would need to solve the 3PP problem, though, which is Hard
> (tm).
>
>
>> 4. Ability to change OSNAME that controlled by uname function in Cygwin
>> DLL.
>
>
> Who needs this, and why?
>
To use with native mingw compilers. We change OS to MINGW32 and
autoconf utilities think that it is Mingw shell.

>
>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>> posix_path.
>
>
> Why do you need this?
For backward compatibility with old MSYS and users experience of using MSYS.

>
> Doesn't it conflict with your point #3?  A portable Cygwin would go out of
> its way to avoid using /etc/fstab.  I would guess that such a Cygwin variant
> would simply provide an unchangeable default behavior, and you'd have to be
> happy with it.
>
No it doesn't conflict. Sometimes you need mount points. File
/etc/fstab doesn't break any portability option)

>
>> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>> used in all situations. From the other side - Win32 applications
>> doesn't understand Cygwin symlinks. As fallback option we need to
>> create copies of files and directories instead symlinks.
>
>
> Copy semantics are not an acceptable fallback for ln.  (Or where they are,
> you can do your own copying.)
>
> Example:
>
>     $ ln -s dir1 dir2
>
> Cygwin decides it can't make the symlink, so it spends a lot of I/O and disk
> space cloning the tree.  Bad enough.  But then:
>
>      $ vi dir2/somefile.txt
>      (make edits, :wq)
>
> Now dir2/somefile.txt is not the same as dir1/somefile.txt.
>
> This is going to break something, I'm sure of it.
>
For Win32 applications we cannot use Cygwin symlinks - only native.
But native symlinks sometimes can't be used - you haven't privileges
for it, filesystem doesn't support it.

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



More information about the Cygwin mailing list