On Fri, Mar 23, 2007 at 07:17:08PM +0200, Pavel Tsekov wrote: > Hmm.. I am not convinced that this patch is necessary. Why do you want > the symlink to have an extension ? Who handles the symlinks on OS/2 ? > Are you using some kind of a Linux/Unix emulator for OS/2 or you just > have a set of GNU utilities ported for OS/2 ? In the former case > it would be up to the emulator to interpret the symlink correctly > (as is done in Cygwin), if it is the latter case I think the copy of > the `ln' utility should do the right thing i.e. add the .exe extension > if necessary.
I am a user, not a developer, so don't expect very technical answers. I suppose there are really two issues. In "$(LN_S) mc mcview" I think the source name 'mc' has to be wrong, because the executable that was built earlier is not 'mc', it is 'mc$(EXEEXT)'. Regarding an extension for the symlink itself, I hadn't really thought about it. I just expected that a symlink would follow whatever naming convention the operating system used. And it is what some other apps do, like Gawk and Ncurses. I think GNU coreutils does also, but the coreutils Makefile is so convoluted it makes me dizzy. As a general principle, if an operating system uses an executable extension, the extension must say something significant about the file. Think of a shell that depends on the extension to determine what names to offer when doing filename completion. It seems reasonable for a Makefile to assume that if a filename's extension is significant, it has the same significance when the "filename" is a symlink. But if using the extension would break anything in Cygwin, don't do it. MC doesn't claim to support OS/2 or any hypothetical operating systems anyway. I only mentioned it because it looked like an oversight that affected portability in general. OS/2's EMX is sometimes called an emulator, but it is more like the second situation you describe. Unix ports can run from a normal OS/2 command line like anything else, they just need to load an extra dynamic library. That's the good part. OS/2's HPFS filesystem has no symlinks, but symlinks can be emulated by creating a dummy file with a 'symlink' extended attribute. It's a convention borrowed from the Linux HPFS module. The bad part of the scheme is that symlink support has to be compiled into each application. I can create symlinks with 'ln', I can zip, unzip, and rsync them, but I cannot execute a symlink because I don't (yet) have a shell that understands how to resolve it. That is why symlinks are not commonly used on OS/2. The new GCC and LibC may change that eventually. But for now Makefiles or config.site scripts usually play it safe and define "LN_S = cp -p". Naturally, when make does "cp -p mc.exe mcview" it does not give the intended result. Anton _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel