This is the mail archive of the
mailing list for the Cygwin project.
Re: Adding MSYS functionality to Cygwin
- From: Warren Young <warren at etr-usa dot com>
- To: Cygwin-L <cygwin at cygwin dot com>
- Date: Tue, 18 Jun 2013 13:10:06 -0600
- Subject: Re: Adding MSYS functionality to Cygwin
- References: <CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw at mail dot gmail dot 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?
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.
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?
5. Use shorted mount point options in /etc/fstab - only win32_path and
Why do you need this?
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.
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.)
$ 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple