Subject: Re: Shortcuts as symlinks (was: v18 vs v17 compile times....)
From: [email-masked] ("Mikey")

26 May 1997 15:14:33 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook Express 4.71.0544.0
Original-To: "Ken Keys" <[email-masked]>
Original-Cc: "cygnus gnu-win32 mailing list" <[email-masked]>
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Original-Sender: [email-masked]

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.

([email-masked])
       the return address for this message is anti spammed
       remove * from the above address to reply.
       Mikey
 ----
From: Ken Keys <[email-masked]>

>Michael Condict ([email-masked]) 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
"[email-masked]" with one line of text: "help".