From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 17 Apr 2003 14:03:23 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 101 ************************************************** Wednesday 16 April 2003 Number 101 ************************************************** Subjects for today 1 Re: Newbie : Yuri Dario" 2 Re: Newbie : Nicky Morrow 3 Re: Newbie : Steve Wendt 4 Re: Newbie : Arnstein.Prytz at jcu.edu.au 5 Re: Newbie : Arnstein.Prytz at jcu.edu.au 6 Re: Newbie : John Poltorak 7 Re: Newbie : John Poltorak 8 hostname.exe : John Poltorak 9 Re: Newbie : Steve Wendt 10 Re: Newbie : Nicky Morrow 11 Re: Newbie : Nicky Morrow 12 Re: eFDS-1.TXT : Steve Wendt 13 Re: InnoTek GCC for OS/2! : Steve Wendt" 14 Re: eFDS-1.TXT : Steve Wendt" 15 Re: eFDS-1.TXT : Steve Wendt" 16 Re: Newbie : John Poltorak 17 Re: eFDS-1.TXT : Nicky Morrow 18 Re: eFDS-1.TXT : Nicky Morrow **= Email 1 ==========================** Date: Thu, 17 Apr 2003 10:14:30 +0200 (CDT) From: "Yuri Dario" Subject: Re: Newbie Hi John, >If TMP is not in the root directory, quite a lot of Unix programs will >fail to access files in %TMP%. happens. >Both TMP and ETC are directly off the root in Unix, and I like them to be >in the same place on OS/2. since OS/2 has drive letters, with a TMP/ETC dir on a drive different from the program default, will still make the program fail. So programs must process %TMP% and %ETC% to find the proper place: this makes moving etc out of \mptn useless (at least from program point of view, maybe it is better for end users). Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 2 ==========================** Date: Thu, 17 Apr 2003 12:04:10 -0300 From: Nicky Morrow Subject: Re: Newbie John Poltorak wrote: >>>I suspect that UnixOS/2 can be generally self-contained >>>although it would be nice if eCS used sensible default definitions for TMP >>>and ETC such as %BOOTDRIVE%\tmp and %BOOTDRIVE%\etc. >>> >>> >>> >>eFDS-1 does define the location and purpose of the tmp directory...it >>even adds a standard config.sys statement (you will find this in eCS >>v1.1). It is isn't %BOOTDRIVE%\tmp. Tell me why you want it this way. >> >> > >If TMP is not in the root directory, quite a lot of Unix programs will >fail to access files in %TMP%. > Please correct me if I'm using faulty logic but there are definate differences that have to be accounted for when porting Unix code to run on OS/2. While it may be acceptable to hardcode directories in Unix programs, in my mind that is not acceptable for the Unix ports to OS/2 to have hardcoded directories. >Both TMP and ETC are directly off the root in Unix, and I like them to be >in the same place on OS/2. > I joined this list in an effort to work issues like this...well, not for OS/2 but rather eCS. Serenity and the folks in the eCSDevGroup are very serious about making eCS into a world class operating system. The fact that I'm here taking your inputs should be a very loud clear message to the folks on this list. With that said, as coordinator of eFDS-1.TXT I often find myself between competing interest. I try to maintain a neutral stance on issues so as to better accomplish the job of pulling the document together. Everything that goes into this document has to be sold to the folks in the eCSDevGroup first and ultimately to Serenity. What makes it easy for me to sell changes and additions? Darn good solid logic. Ultimately the question "How is this going to sell more copies of eCS?" has to be addressed. Certainly "I like them to be in the same place in OS/2" is a valid arguement as the more a person likes something the more likely he is to buy it but I really need a more comprehensive arguement to sell putting "tmp" and "etc" in the root. Please keep in mind that both "tmp" and "etc" have been discussed at length by the folks in the eCSDevGroup. As you see in eFDS-1 and you, hopefully, will see when you get your new copy of eCS v1.1 "tmp" is addressed: Entries in config.sys: SET TMP=x:\var\temp SET TEMP=x:\var\temp SET TMPDIR=x:\var\temp Installer created directory: \var\temp My opinion: It would be a very tough sell to change this to \tmp as one of the goals of eFDS-1 is simplification of the directory structure over the long term. Adding a new root directory is not viewed as heading toward that goal as we already have too many root directories to deal with. On the other hand, it probably is possible to sell a change to: Entries in config.sys: SET TMP=x:\var\tmp SET TEMP=x:\var\tmp SET TMPDIR=x:\var\tmp Installer created directory: \var\tmp It would make changes like this much easier for me to sell if I can say that the UnixOS2 Group requests the following changes. I'm not familiar with the organization structure here but if the spokesperson were to poll the members on various issues and forward the additions and changes when the majority are in favor and the reasons then it would do a long way in helping get things done. Concerning "\etc": By Linux standards "etc" is for static nonshareable files. It isn't clear how this directory fits into a plan for the future eCS file and directory structure. I'm willing to fight the good fight for it to be in the root "\etc" or whereever but it isn't clear to me why this is needed (and it currently is not in eFDS-1 or eCS v1.1). > >The usual location of ETC is only under \MPTN because it isn't required >before MPTS is installed, although, if is defined beforehand, the >existing location is accepted. It was originally placed under \TCPIP, >before MPTS was developed so there has never been any real requirement for >it to be 'owned' by MPTS. Since ETC is not exclusively used by MPTS or >IBM supplied software there is no justification in putting it under \MPTN. > Understand. If "etc" should be defined beforehand, please tell me where and why? Like I said above, it would help the case to make this addition if the "where and why" was a group decision. Last thought: Some of the issues I'm bring up here are difficult to visualize without the operating system in front of you. I'm already running eCS v1.1ga as I'm a tester and I can see and use the changes that have been made. If you haven't already ordered eCS v1.1, please do consider it, I've used OS/2 since v1.3 and this release of eCS is by far the best ever. While not perfect yet, do consider buying it to support the effort. This is an effort by a very small company on a small budget. A lot of the work is done by volunteers. It is basically a miracle that this project is happening. Your support is appreciated. (Unpaid announcement mode off ) Regards, Nick **= Email 3 ==========================** Date: Thu, 17 Apr 2003 12:26:19 -0700 (PDT) From: Steve Wendt Subject: Re: Newbie On Thu, 17 Apr 2003, Nicky Morrow wrote: > While it may be acceptable to hardcode directories in Unix > programs, in my mind that is not acceptable for the Unix ports to OS/2 > to have hardcoded directories. Exactly... > \var\temp > \var\tmp I doubt it makes little difference whether the 'e' is there or not. ;) > that the UnixOS2 Group requests the following changes. I'm not familiar > with the organization structure here but if the spokesperson were to organization structure? Surely you jest. ;) > fight for it to be in the root "\etc" or whereever but it isn't clear to > me why this is needed (and it currently is not in eFDS-1 or eCS v1.1). It's not needed - it's John's preference... **= Email 4 ==========================** Date: Thu, 17 Apr 2003 13:10:50 +1100 From: Arnstein.Prytz at jcu.edu.au Subject: Re: Newbie > If TMP is not in the root directory, quite a lot of Unix programs will > fail to access files in %TMP%. > > Both TMP and ETC are directly off the root in Unix, and I like them to be > in the same place on OS/2. True. TMP is often expected off the ROOT directory. Under OS/2 this does not have an equivalent. In order to be sure that those programs which do not respect %TMP% continue to work, you must have /tmp on each of the drives/partitions that you will be running the program from. I have d:, e:, f:, g:, h: and i: here, not counting CDs, zips and usb flash drives. The program can still be on a separate partition of course. Regards, Arnstein ---------------------------------------------------------------------------- Arnstein Prytz Arnstein.Prytz at jcu.edu.au School of Maths and Physics ph: 61-7-47815183 James Cook University fax: 61-7-47815880 Townsville, Queensland 4811, Australia ---------------------------------------------------------------------------- **= Email 5 ==========================** Date: Thu, 17 Apr 2003 13:10:50 +1100 From: Arnstein.Prytz at jcu.edu.au Subject: Re: Newbie > If TMP is not in the root directory, quite a lot of Unix programs will > fail to access files in %TMP%. > > Both TMP and ETC are directly off the root in Unix, and I like them to be > in the same place on OS/2. True. TMP is often expected off the ROOT directory. Under OS/2 this does not have an equivalent. In order to be sure that those programs which do not respect %TMP% continue to work, you must have /tmp on each of the drives/partitions that you will be running the program from. I have d:, e:, f:, g:, h: and i: here, not counting CDs, zips and usb flash drives. The program can still be on a separate partition of course. Regards, Arnstein ---------------------------------------------------------------------------- Arnstein Prytz Arnstein.Prytz at jcu.edu.au School of Maths and Physics ph: 61-7-47815183 James Cook University fax: 61-7-47815880 Townsville, Queensland 4811, Australia ---------------------------------------------------------------------------- **= Email 6 ==========================** Date: Thu, 17 Apr 2003 14:23:38 +0100 From: John Poltorak Subject: Re: Newbie On Wed, Apr 16, 2003 at 02:46:00PM -0700, Steve Wendt wrote: > On Wed, 16 Apr 2003, John Poltorak wrote: > > > If TMP is not in the root directory, quite a lot of Unix programs will > > fail to access files in %TMP%. > > I would say this is a bug in the respective program... Feel free to correct every program at fault... -- John **= Email 7 ==========================** Date: Thu, 17 Apr 2003 14:27:21 +0100 From: John Poltorak Subject: Re: Newbie On Thu, Apr 17, 2003 at 01:10:50PM +1100, Arnstein.Prytz at jcu.edu.au wrote: > > If TMP is not in the root directory, quite a lot of Unix programs will > > fail to access files in %TMP%. > > > > Both TMP and ETC are directly off the root in Unix, and I like them to be > > in the same place on OS/2. > > True. TMP is often expected off the ROOT directory. Under OS/2 this does > not have an equivalent. In order to be sure that those programs which do > not respect %TMP% continue to work, you must have /tmp on each of the > drives/partitions that you will be running the program from. I have d:, > e:, f:, g:, h: and i: here, not counting CDs, zips and usb flash drives. Can you give me an example of a program which will not accept c:\tmp when you are doing some processing on a different partition? This may be due to problems with the SHELL you are using... > Regards, Arnstein > ---------------------------------------------------------------------------- > Arnstein Prytz Arnstein.Prytz at jcu.edu.au > School of Maths and Physics ph: 61-7-47815183 > James Cook University fax: 61-7-47815880 > Townsville, Queensland 4811, Australia > ---------------------------------------------------------------------------- > -- John **= Email 8 ==========================** Date: Thu, 17 Apr 2003 15:22:28 +0100 From: John Poltorak Subject: hostname.exe I am aware of three hostname programs; they are provided in MPTS, BIND, and GNU Shell Utils. Which one works correctly? Are there any docs on how each of them actually determines hostname? -- John **= Email 9 ==========================** Date: Thu, 17 Apr 2003 15:44:06 -0700 (PDT) From: Steve Wendt Subject: Re: Newbie On Thu, 17 Apr 2003, Nicky Morrow wrote: > Let me ask you this: Are there particular cli utilities that you would > like to see included by default in the next release of eCS (v2)? I also > serve as the team leader for the eCSDevGroup Utilities Team. Including > high quality cli utilities is on the agenda. We added some for eCS v1.1 > but will be looking for more for v2. Do you have a list of what has been added? **= Email 10 ==========================** Date: Thu, 17 Apr 2003 16:02:33 -0300 From: Nicky Morrow Subject: Re: Newbie Nicholas Sheppard wrote: >>Concerning \etc. This directory is not included in the document nor is >>it planned right now. The folks who have provided input to this point >>do not like the idea of adding a \etc directory. Please explain to me >>what the \etc is and/or would be used for and why it needs to be in a >>particular location...and if not in the root what is an acceptable >>alternate location based on eFDS-1. >> >> > >/etc in Unix is used for system-wide configuration files such as the >password file, network configuration, default settings for users, and so >on. As I read the eFDS draft, this would be equivalent to \var\cfg. > You are reading the draft correctly...however, this is an area that requires more work. We didn't get this implemented in eCS v1.1. There are several different kinds of configuration files in the various parts of OS/2 and we are going to have to really be careful how we proceed. What should we do with the system ini's? One idea: SET USER_INI=x:\home\\cfg\user.ini SET SYSTEM_INI: SET SYSTEM_INI=x:\var\cfg\system.ini Note: In discussions on this issue there are folks that argue strongly that instead of using cfg we should use etc. SET USER_INI=x:\home\\etc\user.ini SET SYSTEM_INI: SET SYSTEM_INI=x:\var\etc\system.ini Using \var may be a poor choice for the system ini. Maybe this is better? SET USER_INI=x:\home\\etc\user.ini SET SYSTEM_INI: SET SYSTEM_INI=x:\home\\etc\system.ini Think about it from a backup perspective. Both of these ini's really should be backed up. If they are in the \home directory that keeps things clean as far as the \home directory is the directory for things that needs to be backed up. \var is variable data but is generally for things that you can throw in the bitbucket without too much worry. Keep in mind the basic scheme we are operating from: \ecs - static, nonshareable files -- read-only -- will not be made available on the lan -- must be located on host system -- must be on the boot volume \home - variable, shareable files -- read-write -- may be made available on the lan -- does not need to be located on the host system -- does not need to be on the boot volume \programs - static, shareable files -- read-only -- may be made available on the lan -- does not need to be located on the host system -- does not need to be on the boot volume \var - variable, nonshareable files -- read-write -- will not be made available on the lan -- must be located on host system -- does not need to be on the boot volume The system and user ini files in OS/2 are not static files as are found in \etc in the Linux world. I'm certainly not a *nix expert so if anyone has comment as to how the best way to handle these files I'd love to hear it. The one thing I think we can agree on is that \os2\os2.ini and \os2\os2sys.ini are not a good answer. >Maybe there would be an argument for having \ecs\cfg or suchlike instead >of \var\cfg, I'm not sure, but I don't see any need for it to be in the >root directory. So long as everybody knows where to find the global >configuration, it will work. > There may be a good arguement for \ecs\etc or \ecs\cfg. I do think we need to establish a good default SET ETC=? in the config.sys...other than SET ETC=X:\MPTN\ETC. I'm just not sure what the answer is, let along what benefit any particular choice would bring. >>>I would also like >>>to see a standard PASSWD and GROUP file as part of an OS/2 install. >>> >>> > > > >>I can add this to the eCS projects document. Can I get you to back up, >>give me some history on this issue and give me a very basic definition >>of what you want? >> >> > >For me, the essential requirement is that we have some standard way of >implementing OS/2 applications that require multiple users, i.e. an API >such as POSIX getpwent() etc. But eCS isn't a re-implementation of Unix >and the underlying implementation of that doesn't have to do it the Unix >way (with /etc/passwd and co.) > Got it. This is definately on the todo list. Regards, Nick **= Email 11 ==========================** Date: Thu, 17 Apr 2003 18:00:42 -0300 From: Nicky Morrow Subject: Re: Newbie John Poltorak wrote: >>>If TMP is not in the root directory, quite a lot of Unix programs will >>>fail to access files in %TMP%. >>> >>> >>> >>Please correct me if I'm using faulty logic but there are definate >>differences that have to be accounted for when porting Unix code to run >>on OS/2. While it may be acceptable to hardcode directories in Unix >>programs, in my mind that is not acceptable for the Unix ports to OS/2 >>to have hardcoded directories. >> >> > >Are *you* going to fix things which you consider to be broken? > That depends on how badly I need or want something. I'm not a person that enjoys pain that much so generally broken things go in the bitbucket...and proggies that have hardcoded directories are broken imho. > >I doubt it... In any case, many Unix programs are simply getting built on >OS/2 straight from the original source without any porting at all. > That is just the way it goes. > > > >>Entries in config.sys: >> >> SET TMP=x:\var\temp >> SET TEMP=x:\var\temp >> SET TMPDIR=x:\var\temp >> >> > >I'm sure this will cause problems. I would prefer x:\tmp, although in the >case of TEMP, I'm not really sure if any Unix programs use it... but it >doesn't make sense setting it elsewhere. > Understand. > > >>It would make changes like this much easier for me to sell if I can say >>that the UnixOS2 Group requests the following changes. I'm not familiar >>with the organization structure here but if the spokesperson were to >>poll the members on various issues and forward the additions and changes >>when the majority are in favor and the reasons then it would do a long >>way in helping get things done. >> >>Concerning "\etc": By Linux standards "etc" is for static nonshareable >>files. It isn't clear how this directory fits into a plan for the >>future eCS file and directory structure. I'm willing to fight the good >>fight for it to be in the root "\etc" or whereever but it isn't clear to >>me why this is needed (and it currently is not in eFDS-1 or eCS v1.1). >> >> > >ETC is purely related to TCP/IP and Unixy-type things. It doesn't really >impact on eCS (or OS/2) for anything else. > As it doesn't appear this issue is in need of repair I'll look elsewhere for issues to work on. > > > >>>The usual location of ETC is only under \MPTN because it isn't required >>>before MPTS is installed, although, if is defined beforehand, the >>>existing location is accepted. It was originally placed under \TCPIP, >>>before MPTS was developed so there has never been any real requirement for >>>it to be 'owned' by MPTS. Since ETC is not exclusively used by MPTS or >>>IBM supplied software there is no justification in putting it under \MPTN. >>> >>> >>> >>Understand. If "etc" should be defined beforehand, please tell me where >>and why? Like I said above, it would help the case to make this >>addition if the "where and why" was a group decision. >> >> > >Ideally ETC would be set to %UNIXROOT%\etc, but UNIXROOT can be anywhere. >I prefer it on the bootdrive. But it shouldn't really matter where it >goes. > >The location of %ETC% and /etc have been discussed many times. Some people >are happy to see %ETC% as c:\mptn\etc and /etc as %UNIXROOT%/etc, ie as >completely seperate, unconnected entities, but I prefer to see them as the >same directory. That's my personal view, and that's how I set things up on >my systems. I don't think you will get a group decision on this? > Understand. Pressing on to greener grass... Let me ask you this: Are there particular cli utilities that you would like to see included by default in the next release of eCS (v2)? I also serve as the team leader for the eCSDevGroup Utilities Team. Including high quality cli utilities is on the agenda. We added some for eCS v1.1 but will be looking for more for v2. Regards, Nick **= Email 12 ==========================** Date: Thu, 17 Apr 2003 18:49:22 -0700 (PDT) From: Steve Wendt Subject: Re: eFDS-1.TXT On Fri, 18 Apr 2003, Andreas Buening wrote: > As other people have already suggested: There may be more than one > home directory (/home, /home2, /home3) or /home may have another > name. Even for Unix /home is not fixed so I'd suggest to use just > $HOME for it. Yes, but $HOME (or %HOME% if you prefer) could be set to x:\home\username, and thus be compatible with both... > > The \home directory shall contain only subdirectories which in turn > > This is in contradiction to the Unix /home directory. I'm not sure I follow your meaning on this one... /home generally contains subdirectories for various users. > FHS makes a difference between /tmp and /var/tmp. The latter is supposed > to be persistent (though I haven't ever seen a system where /tmp is > cleaned at startup). /tmp does get automatically cleaned out periodically on some machines, though. I forget the name of the daemon that does this... > > SET TMP=x:\var\temp > > SET TEMP=x:\var\temp > > SET TMPDIR=x:\var\temp > > OS/2 used to support that the temp dir is relocatable by the env. vars > TMP and TEMP. So I see no need for a hardcoded name at this point. > TMPDIR is used by some Unix apps as an alternative to a hardcoded /tmp > so please don't use it in the eFDS. If I understand correctly, these are not hardcoded, just the defaults. They are still environment variables, and can thus be changed by the user to whatever they want them to be. **= Email 13 ==========================** Date: Thu, 17 Apr 2003 19:53:07 -0700 (PDT) From: "Steve Wendt" Subject: Re: InnoTek GCC for OS/2! On Wed, 16 Apr 2003 00:10:52 +0200, Kris Steenhaut wrote: >> http://www.innotek.de/products/gccos2/ > >Ugh? You are prepared to put $ 25.000 out of your pocket? You only have to pay for defect support. Otherwise, it is supposed to be freely available... ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 14 ==========================** Date: Thu, 17 Apr 2003 20:12:43 -0700 (PDT) From: "Steve Wendt" Subject: Re: eFDS-1.TXT On Thu, 17 Apr 2003 22:22:29 -0300, Nicky Morrow wrote: >Absolutely. That is why I'm here. Not only do we not need UnixOS2 and >eCS to not conflict with each other, it would be good if they can >compliment each other. Your shell prompt is so nice... Thanks, your widgets are beautiful... Oh, you meant *complement* each other. ;) >> Even for Unix /home is not fixed so I'd suggest to use just >>$HOME for it. Problem: Should HOME use forward or backward slashes? > >We don't have a choice, the underlying os is OS/2 so it must be a backslash. There *is* a choice if your shell can handle forward slashes. The WPS can, but cmd.exe can't (and many OS/2 programs likely can't). XFree86/OS2 (for example) expects forward slashes for some things, unless that changed with the 4.3 port. > 2-17-03 3:40p 56,740 0 a--- arcview.exe > 3-02-93 12:12p 1,652 0 a--- boot2c.com > 5-18-02 7:22a 11,284 0 a--- bootlist.exe >12-09-02 6:47a 7,378 0 a--- brandldr.exe > 4-04-01 4:44p 116,491 0 a--- ecscalc.exe > 1-19-03 4:48p 65 0 a--- mem.cmd > 1-19-03 4:48p 15,323 0 a--- memory.exe > 4-02-01 3:26a 803 1,053 a--- of.cmd > 2-05-03 7:03a 392 0 a--- open.cmd > 9-21-02 7:49p 53,072 0 a--- pmprintf.exe > 2-26-03 9:58p 6,682 0 a--- protochk.cmd > 2-14-03 11:08a 8,258 0 a--- reader.exe > 4-04-01 2:51p 7,718 0 a--- shutdown.exe > 9-20-02 1:22p 30,484 0 a--- smartctl.exe > 3-19-03 3:49p 1,206 2,297 a--- wrap$$$$.cmd Are there descriptions of these somewhere, and/or an indication of where they came from? > 9-20-02 1:22p 27,709 0 a--- diskinfo.exe > 9-20-02 1:22p 28,738 0 a--- dumpide.exe These come from danis506, apparently. > 6-30-99 1:27p 88,045 0 a--- RC.EXE > 6-30-99 1:27p 15,314 0 a--- RCPP.ERR > 6-30-99 1:27p 47,331 0 a--- RCPP.EXE Why are these not in \os2 where they usually live? > 4-12-02 11:53a 14,586 30,363 a--- rdc.cmd > 2-17-96 11:29a 14,241 0 a--- rdc.old > 4-12-02 11:52a 13,264 0 a--- rdc2.exe > 5-27-95 5:44a 31,700 0 a--- rdcpp.exe > 2-17-96 11:34a 8,768 13,688 a--- resmgr.cmd > 9-21-02 1:17p 3,943 0 a--- resmgr.txt Martin Lafaix's resource decompiler, I assume. > 4-01-02 6:37p 12,559 0 a--- unLock.exe > 2-25-02 3:13p 175,155 0 a--- unzip.exe > 1-09-00 2:34a 122,416 0 a--- zip.exe These are the most essential! Other possibilities might be top, wget, diff, which, grep, rm, and kill. Others may have more suggestions. >For the next version we could add: >\var\cache >\var\spool >What do you think? Don't add them unless something that is installed uses them... ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 15 ==========================** Date: Thu, 17 Apr 2003 20:16:18 -0700 (PDT) From: "Steve Wendt" Subject: Re: eFDS-1.TXT On Thu, 17 Apr 2003 20:12:43 -0700 (PDT), Steve Wendt wrote: >These are the most essential! Other possibilities might be top, wget, diff, which, >grep, rm, and kill. Others may have more suggestions. Oh, and list (LST/2) - how could I forget that one. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 16 ==========================** Date: Thu, 17 Apr 2003 20:32:44 +0100 From: John Poltorak Subject: Re: Newbie On Thu, Apr 17, 2003 at 12:04:10PM -0300, Nicky Morrow wrote: > >If TMP is not in the root directory, quite a lot of Unix programs will > >fail to access files in %TMP%. > > > > Please correct me if I'm using faulty logic but there are definate > differences that have to be accounted for when porting Unix code to run > on OS/2. While it may be acceptable to hardcode directories in Unix > programs, in my mind that is not acceptable for the Unix ports to OS/2 > to have hardcoded directories. Are *you* going to fix things which you consider to be broken? I doubt it... In any case, many Unix programs are simply getting built on OS/2 straight from the original source without any porting at all. > Entries in config.sys: > > SET TMP=x:\var\temp > SET TEMP=x:\var\temp > SET TMPDIR=x:\var\temp I'm sure this will cause problems. I would prefer x:\tmp, although in the case of TEMP, I'm not really sure if any Unix programs use it... but it doesn't make sense setting it elsewhere. > It would make changes like this much easier for me to sell if I can say > that the UnixOS2 Group requests the following changes. I'm not familiar > with the organization structure here but if the spokesperson were to > poll the members on various issues and forward the additions and changes > when the majority are in favor and the reasons then it would do a long > way in helping get things done. > > Concerning "\etc": By Linux standards "etc" is for static nonshareable > files. It isn't clear how this directory fits into a plan for the > future eCS file and directory structure. I'm willing to fight the good > fight for it to be in the root "\etc" or whereever but it isn't clear to > me why this is needed (and it currently is not in eFDS-1 or eCS v1.1). ETC is purely related to TCP/IP and Unixy-type things. It doesn't really impact on eCS (or OS/2) for anything else. > >The usual location of ETC is only under \MPTN because it isn't required > >before MPTS is installed, although, if is defined beforehand, the > >existing location is accepted. It was originally placed under \TCPIP, > >before MPTS was developed so there has never been any real requirement for > >it to be 'owned' by MPTS. Since ETC is not exclusively used by MPTS or > >IBM supplied software there is no justification in putting it under \MPTN. > > > > Understand. If "etc" should be defined beforehand, please tell me where > and why? Like I said above, it would help the case to make this > addition if the "where and why" was a group decision. Ideally ETC would be set to %UNIXROOT%\etc, but UNIXROOT can be anywhere. I prefer it on the bootdrive. But it shouldn't really matter where it goes. The location of %ETC% and /etc have been discussed many times. Some people are happy to see %ETC% as c:\mptn\etc and /etc as %UNIXROOT%/etc, ie as completely seperate, unconnected entities, but I prefer to see them as the same directory. That's my personal view, and that's how I set things up on my systems. I don't think you will get a group decision on this? > Regards, > > Nick -- John **= Email 17 ==========================** Date: Thu, 17 Apr 2003 22:22:29 -0300 From: Nicky Morrow Subject: Re: eFDS-1.TXT Andreas Buening wrote: >Hello Andreas. > >I've commented a lot of points below which I think should be considered. >It's quite a lot. So I tried to keep the comments short. Some points >might be not explained well enough. If anything is unclear, feel free >to blame me. > I've read it all and am now coming back to comment. Very good comments. Thank you. I'm not an experienced unix user and am learning a lot here. > >First I want to mention that eCS and UnixOS/2 are different approaches >and they shouldn't screw up each other. I.e. there should be no >name clashes for env. vars or directory names. > Absolutely. That is why I'm here. Not only do we not need UnixOS2 and eCS to not conflict with each other, it would be good if they can compliment each other. > > >> \ecs - intended for static, nonshareable files >> -- read-only >> -- will not be made available on the lan >> -- must be located on host system >> -- must be on the boot volume >> >> \home - intended for variable, shareable files >> -- read-write >> -- may be made available on the lan >> -- does not need to be located on the host system >> -- does not need to be on the boot volume >> >> > >As other people have already suggested: There may be more than one >home directory (/home, /home2, /home3) or /home may have another >name. > You are about the 3rd person to mention this. It is in line with what we were thinking but we had not put it in the document. Correct me if I'm wrong but a slight modification could be in order for eCS since it does use volume identifiers (otherwise known as drive letters). It should read as: "There may be more than one home directory on a host system but a maximum of one per volume." How does that read? Should that not apply to \programs as well? > Even for Unix /home is not fixed so I'd suggest to use just >$HOME for it. Problem: Should HOME use forward or backward slashes? > We don't have a choice, the underlying os is OS/2 so it must be a backslash. >> \programs - intended for static, shareable files >> -- read-only >> -- may be made available on the lan >> -- does not need to be located on the host system >> -- does not need to be on the boot volume >> >> > >Okay. This is what /opt is intended for on Unix. > Yes, using \opt lost the battle. >> \var - intended for variable, nonshareable files >> -- read-write >> -- will not be made available on the lan >> -- must be located on host system >> -- does not need to be on the boot volume >> >> END RATIONALE >> >> > >[snip] > > > >> \ecs\bin essential command binaries (no subdirectories allowed) >> >> > >[snip] > > > >> NOTE: \ecs\bin and \ecs\system both contain essential binaries but they >> are for very different purposes. \ecs\system contains only directories >> that hold files related to large complex packages, while \ecs\bin is for >> standalone system utilities. >> >> > >Which binaries exactly? Where are the standard OS/2 and DOS tools? > The OS/2 and DOS utilities that you are used to are still where they have been for years. As time passes that may change but that is down the road. \ecs\bin is for additional, eCS added utilities and stand alone programs: Directory of \ecs\bin 2-17-03 3:40p 56,740 0 a--- arcview.exe 3-02-93 12:12p 1,652 0 a--- boot2c.com 5-18-02 7:22a 11,284 0 a--- bootlist.exe 12-09-02 6:47a 7,378 0 a--- brandldr.exe 9-20-02 1:22p 27,709 0 a--- diskinfo.exe 9-20-02 1:22p 28,738 0 a--- dumpide.exe 4-04-01 4:44p 116,491 0 a--- ecscalc.exe 9-22-02 10:11p 746,718 0 a--- flash5.exe 2-25-02 3:13p 64,051 0 a--- funzip.exe 8-21-93 11:56a 84,005 0 a--- gzip.exe 1-19-03 4:48p 65 0 a--- mem.cmd 1-19-03 4:48p 15,323 0 a--- memory.exe 3-06-03 2:52p 570,034 0 a--- newview.exe 4-02-01 3:26a 803 1,053 a--- of.cmd 2-05-03 7:03a 392 0 a--- open.cmd 9-21-02 7:49p 53,072 0 a--- pmprintf.exe 2-26-03 9:58p 6,682 0 a--- protochk.cmd 6-30-99 1:27p 88,045 0 a--- RC.EXE 6-30-99 1:27p 15,314 0 a--- RCPP.ERR 6-30-99 1:27p 47,331 0 a--- RCPP.EXE 4-12-02 11:53a 14,586 30,363 a--- rdc.cmd 2-17-96 11:29a 14,241 0 a--- rdc.old 4-12-02 11:52a 13,264 0 a--- rdc2.exe 5-27-95 5:44a 31,700 0 a--- rdcpp.exe 2-14-03 11:08a 8,258 0 a--- reader.exe 2-17-96 11:34a 8,768 13,688 a--- resmgr.cmd 9-21-02 1:17p 3,943 0 a--- resmgr.txt 4-04-01 2:51p 7,718 0 a--- shutdown.exe 9-20-02 1:22p 30,484 0 a--- smartctl.exe 7-23-97 2:15p 190,488 0 a--- tar.exe 4-01-02 6:37p 12,559 0 a--- unLock.exe 2-25-02 3:13p 175,155 0 a--- unzip.exe 2-25-02 3:13p 114,739 0 a--- unzipsfx.exe 4-20-02 12:22a 78,673 0 a--- usb.ids 6-09-01 6:11p 337,794 0 a--- usbres.exe 3-19-03 3:49p 1,206 2,297 a--- wrap$$$$.cmd 1-09-00 2:34a 122,416 0 a--- zip.exe 2-25-02 4:27p 2,178 0 a--- zip2exe.cmd 2-25-02 4:27p 1,657 0 a--- zipgrep.cmd 1-09-00 2:34a 66,608 0 a--- zipnote.exe 1-09-00 2:34a 68,144 0 a--- zipsplit.exe \ecs\bin is in the PATH. >\os2\*? Only for eCS tools or is this intended for all standalone >programs? It makes sense to have one _system_ bin dir for the OS itself >and one user/third party bin dir (to be screwed up by the user) as it is >the case for /usr/bin versus /usr/local/bin on Unix. > \ecs\system is used to add major operating system packages such as the eCS version of XWorkPlace which is located in \ecs\system\ewps. The eCS version of Styler/2 is located in \ecs\system\estyler. Those packaged are heavily integrated into the os now. 3rd party add-ons could go in \programs\? or in other places depending on various issues. > >[snip] > > > >> The \programs directory shall contain only subdirectories which in turn >> will contain the files and subdirectories specific to a particular >> application. >> >> > >What about special files like *.inf? > \ecs\book > You could support e.g. a \program\book >dir where programs could (but needn't) store their docs. > Directory of \ecs 4-10-03 6:07p 1,872 ---- bin 4-10-03 6:07p 461 ---- book 4-10-03 6:07p 0 ---- boot 4-10-03 6:07p 846 ---- dll 3-19-03 9:18p 720 ---- doc 4-10-03 6:07p 0 ---- help 4-10-03 6:07p 0 ---- install 4-10-03 6:07p 0 ---- lang 4-10-03 6:07p 627 ---- system book, doc and help hold their respective type of files. >> The \home directory shall contain only subdirectories which in turn >> >> > >This is in contradiction to the Unix /home directory. > We are aware of this. \home is not fully implemented in this version because we don't have multiuser support ready. > > The \var directory shall contain the following directories: > > \var\cfg application configuration files that contain data not > specific to an individual user > \var\log .log files (no subdirectories allowed) > \var\temp temporary files (no subdirectories allowed) > > > >Unix also has /var. FHS requires config files to be in /etc not in /var. >FHS makes a difference between /tmp and /var/tmp. The latter is supposed >to be persistent (though I haven't ever seen a system where /tmp is >cleaned at startup). > This is definately a discussion item. For this release of eCS you will see only: \var\log \var\temp For the next version we could add: \var\cache \var\spool What do you think? > > > >> unzip.exe The unzip unarchiving utility >> zip.exe The zip archiving utility >> >> > >FHS also requires zip and unzip in its tree. > > > SET TMP=x:\var\temp > SET TEMP=x:\var\temp > SET TMPDIR=x:\var\temp > > > >OS/2 used to support that the temp dir is relocatable by the env. vars >TMP and TEMP. > It still does. You can change the above to whatever you want. We are simply providing a system default. > So I see no need for a hardcoded name at this point. > They aren't hardcoded. >TMPDIR is used by some Unix apps as an alternative to a hardcoded /tmp >so please don't use it in the eFDS. > We can pull tmpdir out before v2 ships (it will be in v1.1 which is shipping right now)...can you be more specific as to why it should be pulled? > Additionally TMPDIR should use forward slashes. > No can do. OS/2 is the underlying os, not unix. > > > > >> SET USER_INI=x:\home\\cfg\os2.ini >> >> > >In another posting you asked where to place the ini files. Good question. >I think /home is not the worst place. > I'm inclined to agree. I'll be working that issue. > > eStyler would then locate estyler.ini as such: > > x:\home\stjohnb\cfg\estyler.ini > > > >FHS distinguishes between /etc config files (system wide) and /home >config files (user specific). Btw, if I remember correctly there was >the intention to add a $HOME/config or $HOME/.config file to the next >FHS standard (I'm not sure about the dir name). > >[snip] > >/etc is another story. OS/2 recognizes $ETC and there's nothing wrong >with it. Everbody should be able to put $ETC whereever he wants. >On the other hand Unix also has /etc which is more or less hardcoded. >eCS and ux2 users should be able to use ONE /etc dir for both. So maybe >ETC=%BOOTDRIVE%\etc could be a reasonable default for OS/2. > It could be a reasonable default but that would a hard battle to win. I think I'm going to hold off on adding anything concerning etc for now. Cheers, Nick **= Email 18 ==========================** Date: Thu, 17 Apr 2003 23:56:13 -0300 From: Nicky Morrow Subject: Re: eFDS-1.TXT Steve Wendt wrote: >>> The \home directory shall contain only subdirectories which in turn >>> >>> >>This is in contradiction to the Unix /home directory. >> >> > >I'm not sure I follow your meaning on this one... /home generally contains >subdirectories for various users. > That is exactly how \home is being implemented in eCS. On my system you will find: \home\default \home\morrownr (my folder) \home\morrowne (my wife's folder) In my folder you will find: \home\morrownr\desktop (each user has to have his/her own desktop) \home\morrownr\cfg (for user.ini, system.ini and application ini's) ...I also have a lot of program data folders and other data folders to hold, for example, picture files. >>FHS makes a difference between /tmp and /var/tmp. The latter is supposed >>to be persistent (though I haven't ever seen a system where /tmp is >>cleaned at startup). >> >> > >/tmp does get automatically cleaned out periodically on some machines, >though. I forget the name of the daemon that does this... > > > >>> SET TMP=x:\var\temp >>> SET TEMP=x:\var\temp >>> SET TMPDIR=x:\var\temp >>> >>> >>OS/2 used to support that the temp dir is relocatable by the env. vars >>TMP and TEMP. So I see no need for a hardcoded name at this point. >>TMPDIR is used by some Unix apps as an alternative to a hardcoded /tmp >>so please don't use it in the eFDS. >> >> > > >If I understand correctly, these are not hardcoded, just the defaults. >They are still environment variables, and can thus be changed by the user >to whatever they want them to be. > That is correct. Regards, Nick