Mail Archives: cygwin/1997/05/26/15:14:33
Ken symlinks to executables do work.
(at least on win95 with binary mounts)
type in
cd /
ln -s /usr/H-i386-cygwin32/bin/bash.exe /bin/sh
and see what happens.
note do not link to sh.exe link to sh.
(*jeffdb AT netzone DOT com)
the return address for this message is anti spammed
remove * from the above address to reply.
Mikey
----
From: Ken Keys <hawkeye AT CommerceWave DOT com>
>Michael Condict (m DOT condict AT opengroup DOT org) wrote:
>
>> I'd like to step back and point out that Windows 95 / NT 4 already *have*
>> symlinks. They are ".lnk" files for folders, data files and Win32 programs,
>> and ".pif" files for 16-bit programs. They have all the power of UNIX
>> symlinks in what information is stored in them, and more.
>>
>> Now it's true that Windows makes very poor use of these symlinks,
>> allowing them to have meaning only if you double-click on them in an
>> Explorer window or feed them to the "Run" menu or the "start" command.
>> You can't "cd" through them or print the contents of the file to which
>> they point using the "type" command. But this is no reason that Cygnus
>> Win32 can't endow them with the full power of UNIX symlinks. This would
>> be a solution that does not require reading a symlink file.
>>
>> It's also much better integrated with Windows. Wouldn't it be nice if
>> you could navigate through Cygnus Win32 symlinks using Explorer? When
>> you've made c:/bin be a symlink/shortcut to the Cygnus godawfully named
>> ".../H-i386-cygwin32/bin" directory, wouldn't it be nice if you could
>> type e.g. "/bin/bash" to the Start / Run window, and have it start up
>> bash?
>>
>> Here are some details of how such links could work:
>>
>> 1) Readdir, when returning the names of files in a directory,
>> should delete the suffix ".lnk" or ".pif", if present.
>>
>> 2) In the open syscall, if an attempt to open a file fails with
>> a "not found" error, open should suffix ".lnk" and try
>> again. If that fails, it should suffix ".pif" and try
>> again. If either of these succeeds, open should then read
>> the shortcut file, find the path name of the target, and do a
>> Win32 open of the target file. This will slow down the
>> processing of sym links a bit (because a failed open has to
>> take place first), but allows non-symlink files to be
>> processed without any overhead added by the symlink code.
>>
>> 3) The other syscalls that take a pathname and are supposed to
>> follow symlinks (e.g. chdir, stat), should select the target
>> file or folder similarly to the algorithm used by open.
>
>I agree, this would be very useful. It's so obvious that I wonder why
>it wasn't done in the first place. The only reason I didn't propose it
>myself several weeks ago is that I didn't know enough about how .lnk and
>.pif files really worked.
>
>There is one minor problem with your proposal: readdir can't just delete
>the suffix, since the prefix may not be unique (e.g., files "foo" and
>"foo.lnk" would both look like "foo"). The solution is simply to have
>readdir() not remove the suffix. This would parallel the way ".exe" and
>".bat" files are already handled.
>
>Having symlinks be shortcuts would also allow symlinks to executables to
>work, instead of failing to find the dll as they do currently. (I guess
>the cygwin exec() would have to expand its search to include files
>ending in ".lnk" and ".pif", but it wouldn't have to do anything
>special with them, since the windows calls would take care of the rest.)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -