From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 17 Feb 2003 04:53:32 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 47 ************************************************** Sunday 16 February 2003 Number 47 ************************************************** Subjects for today 1 Re: [Mailman-os2] Mailman 2.1.1 update : Andrew MacIntyre 2 Re: ln : Marty" **= Email 1 ==========================** Date: Mon, 17 Feb 2003 07:32:50 +1000 (est) From: Andrew MacIntyre Subject: Re: [Mailman-os2] Mailman 2.1.1 update On Sun, 16 Feb 2003, John Poltorak wrote: > > passwd = mailman;*;28;28;Mailman;D:/Apps/mailman;D:/bin/sh > > grp = mailman;;28; > > If a PASSWD file is required then I suggest it uses the format proposed > by Nicholas Sheppard in his PINE port. > > We should try and conform to a standard format and use standard passwd > access routines rather than them being specific to Python. > > I don't know if this would need source code changes to Python ... It shouldn't. If it does, that's a bug in my pwd/grp modules. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 2 ==========================** Date: Mon, 17 Feb 2003 20:18:15 -0500 (EST) From: "Marty" Subject: Re: ln On Sat, 15 Feb 2003 18:38:43 +0100 (CET), Stefan Neis wrote: > Hi, > > > It seems that it is essential to have an LN command to be able to get by, > > at least as far as building some apps is concerned. I couldn't build > > diffutils until I created an LN executable. > > > > The question is, what should LN be? A copy of cp.exe or ln.cmd:- ? > > I think it should be something which prints a clear notice on screen that > it is doing a copy instead of a link (so I can delete all the unwanted > copies afterwards ... ;-) ) Why don't we actually try to implement this somehow? I imagine many scripts and makefiles simply won't work as expected on a system that doesn't support soft linking. Here's my proposal: Create an LN executable that creates a blank file where the link is supposed to be. The link target is stored in the extended attributes of this file. Next we modify fopen, open, stat, etc., in our Unix compatibility libraries (be they EMX internals or Posix/2) so that they check for these EAs before opening the file. Then just rebuild our shells and base utilities with these libraries and we're all set (or if they're dynamically linked, we're ready to go without rebuilding). This will give us soft link support in make and the various build scripts, which is really all we need. It will also give any other apps we choose to rebuild the ability to recognize these links. If we wanted to go all out, we could even make our routines recognize desktop shadows, but that won't help our immediate cause (although it will make things appear a lot more integrated with the OS/2 desktop). I'd be glad to take on this work if someone can point me to what I might need to change in our support libraries (and where to get the source) to implement this, and give me any pointers about the pitfalls involved. I'm sure someone has been down this road before.