2013/6/18 Warren Young <war...@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
