RE: EMX on DOS

[Rick Genter]

14 characters was the limit for Unix systems before the so-called "fast file 
system" for 4.2BSD was released back in the early '80s.

--
Rick Genter
Sr. Software Engineer
Silverlink Communications
<mailto:rgenter@silverlink.com>
(781) 272-3080 x242

This e-mail, including attachments, may include confidential and/or proprietary 
information, and may only be used by the person or entity to which it is 
addressed.  If the reader of this e-mail is not the intended recipient or his 
or her authorized agent, the reader is hereby notified that any dissemination, 
distribution or copying of this e-mail is prohibited.  If you have received 
this e-mail in error, please notify the sender by replying to this message and 
delete this e-mail immediately.




-----Original Message-----
From: Derek Robert Price [mailto:derek@ximbiot.com]
Sent: Monday, November 03, 2003 9:44 AM
To: bug-cvs@gnu.org
Subject: Re: EMX on DOS


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Edwards wrote:

|"Derek Robert Price" <derek@ximbiot.com> wrote in message
news:mailman.2985.1067825947.21628.bug-cvs@gnu.org...
|
|>|"Paul Edwards" <kerravon@nosppaam.w3.to> wrote in message
|>news:PpRob.174119$bo1.23941@news-server.bigpond.net.au...
|>|
|>|1. Should I rely on the HAVE_LONG_FILE_NAMES for
|>|the DOS port?
|>
|>You can rely on configure to set it correctly.  If you are going to go
|
|
|But I can I put DOS 8.3 changes within that, or is it used
|for other systems that don't have long filenames, but
|aren't restricted to DOS's 8.3 limitations either?


Whoops.  You are correct.  From the Autoconf manual:

~ - Macro: AC_SYS_LONG_FILE_NAMES
~     If the system supports file names longer than 14 characters, define
~     `HAVE_LONG_FILE_NAMES'.

Of course, HAVE_LONG_FILE_NAMES is only being used in one location in
lock.c.  It might not be terrible if HAVE_LONG_FILE_NAMES (which we are
fairly certain will not be set in a DOS environment) was used to
restrict CVS's files to 8+3 filenames since 8+3 filenames probably work
on whatever system it is that restricts file names to 14 characters.

You should read the sections of the Autoconf manual on DOS portability.
One of them mentions a doschk package which can be used to "easily
detect" some DOS limitations.

|>ahead with a DOS port, you might want to look into DJGPP
|><http://www.delorie.com/djgpp>.  DJGPP is a 32-bit DOS portability
|>layer.  Much like Cygwin, I think, except I think more care was taken to
|>actually provide for DOS quirks like 8.3 filenames.  I've seen the
|>patches come across the Autoconf list for this.  Anyhow, if you hadn't
|>guessed, DJGPP comes with a Bash port to run configure scripts.
|
|
|EMX is a 32-bit DOS portability layer too. I already have
|this installed and already working.  What I don't have is a


What makes EMX preferrable to, say, the GPLed DJGPP or Cygwin?

|working shell program.  Posix compliant should not be dependent
|on having non-Posix extensions that aren't even remotely C.  C
|is what is portable.  Shell is not.  Not all posix systems have


Your platform _can_ run shell.  I don't see why you expect the CVS
development team to deal with your Cygwin installation problems.  It
seems to me that would be a more relevant on a Cygwin list.  In
addition, you might be able to use DJGPP.  I really don't want to spend
very much time resolving problems that have already been solved.  I have
enough to do.

|all the dependencies in configure, but they do have all the things
|required by the Posix 1003.1 standard, ergo why they are posix
|compliant.  My installed and working EMX system only came
|with the compiler.


I'm usually inclined to think of the emx & os2 directories as nusiances,
as as near as I can tell they are usually not in a working order and
receive little support.  Even the windows-NT directory's code remains
broken much of the time due to a lack of developers on the platform and
the lack of test scripts to run there.

Thus, adding another nusiance directory, POSIX or not, to slowly suffer
from bitrot due to lack of support is not particularly appealing to me.
I might reconsider if it meant that we could eliminate one or more of
the other nusiance directories.

|BTW, without changes to CVS source code, it is not possible
|to be able to use the "\" that is used in DOS.


It can't be used in arguments.  It does sometimes come out in the error
messages, which makes it annoyingly complicated to run the sanity.sh
test scripts.

Configure detects PATH_SEPARATOR automatically, and this could then be
defined in config.h if you want to give a shot at fixing that.

|>|2. In filesubr.c I was very surprised to see rename() being
|>|used, without any #ifdefing to say whether rename would
|>|overwrite an existing file.  The C standard leavs it
|>|ambiguous.  Any reason why we don't delete the target
|>|before rename?  I'm surprised this is the first system in this
|>|boat.  It was also necessary to make it writable.
|>
|>filesubr.c is implemented for each platform, with the version in src
|>intended for those platforms which can run configure.
|
|
|Even if they can run configure, there is no option to say
|"my system doesn't allow rename to overwrite an
|existing file".  Not that I saw anyway.  There is one to
|say HAVE_RENAME, but I do have rename, but it
|doesn't overwrite files, as indeed it is not required to do
|by the C89 standard, which I don't expect was written for
|just EMX for DOS.
|
|>There is a
|>separate version in the windows-NT directory, for example.  If the
|>version in src doesn't have a switch for platforms which don't allow
|>renames over existing files, I would guess the issue hasn't been raised
|>previously or nobody noticed if it was.
|
|
|This is for DOS, not Windows.  I raised it and submitted
|a fix.


If this fix is for DOS, then I think you should take a closer look at
DJGPP regardless of whether your EMX "works" or not.

Derek

- --
~                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
- --
Two wrongs do not make a right.  Three lefts do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/pmm1LD1OTBfyMaQRAqGQAKC7bFL1qVtw7u35c6TB3tNyVfl8TwCgsD8S
GkwlAWRYt0C+fiEouZeIq70=
=QLaC
-----END PGP SIGNATURE-----




_______________________________________________
Bug-cvs mailing list
Bug-cvs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-cvs