bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patches for OS/2 (2)


From: Andreas Buening
Subject: Re: Patches for OS/2 (2)
Date: Wed, 13 Nov 2002 00:13:10 +0100

Bruno Haible wrote:
> 
> Andreas Buening writes:
> 
> > I added a __DEBUG__ macro that causes some extra info to
> > be printed to stderr at runtime. It helped me a lot.
> 
> You could just as well have used a .gdbinit with a few breakpoints. No
> need to modify the source for extra info for a single person.  And if
> you want Joe User profit from your extra info then it is wrong make it
> conditional on __DEBUG__.

That code is not for gdb. If a program doesn't show localized
messages or wrong charsets or whatever then this code prints what's
going on in libintl. It helped me a lot to find out what
was going on and also some other users whose programs didn't show
localized messages. If you think it might be usefull build it in,
otherwise don't. That code of mine is for free. ;-)


> > The main problem with libintl is that it is not easy to
> > provide precompiled executables that work on all systems
> > because every user may have its stuff on another drive.
> 
> You can compile the binaries for a fixed virtual
> drive, say U:, and expect the users to ASSIGN/JOIN/SUBST
> U: to where they have installed emx.

1) No matter which drive letter I would choose there would be
   ever lots of people who use exactly that drive for their
   boot drive/CD ROM/ZIP drive/<insert your favorite hardware>.
   Current OS/2 systems allow you to boot from every drive.
   I bet there a people outside who boot from z:. And, of course,
   there needn't be a c: at all.
2) assign/join/subst is a DOS only feature.


> > If the precompiled binaries use prefix=e:/usr/local then
> > libintl can't find the locale files in f:/usr/local etc.
> > If the precompiled binaries use prefix=/usr/local then libintl
> > can find the files in f:/usr/local only if f: is the current
> > drive which means that the program result depends on the
> > choosen current directory.
> > The solution is the following: If a directory name doesn't
> > contain a drive letter x: then the $UNIXROOT drive letter
> > is assumed. If UNIXROOT is not set nothing happens.
> 
> DOS and OS/2 maintain a notion of "current drive". The
> effect that you achieve through UNIXROOT=f: is the same
> as the user would obtain through the command "cd f:".
> The handling of pathnames without drive letters is
> already handled inside EMX. I see no reason to duplicate
> it in the software above it.

No. This would imply that the software only works on the drive
it is installed. To grep some files in the current directory
c:/dir/bla would need

d:
grep "blurb" c:/dir/bla/*.foo
c:
... do_something with the files ...


just because grep would need the current drive to be "d:".
This is very uncomfortable, completely silly and absolutely
unpracticable. Producing binaries that work on all systems
IS a big issue. Using 20000 environment variables, one for
each program is also no solution. Therfore there has been some
agreement that using one variable ("UNIXROOT") for them all.


> > loadmsgcat.c:
> > Initialize _nl_msg_cat_cntr with 0. It's a bad programming style
> > not to do so
> 
> We've already discussed this. BSS allocated variables are ISO C compliant.
> 
> > and under some circumstances it can lead to problems
> > with the OS/2 linker.
> 
> If these "circumstances" can occur with libintl, then you'd better ask
> EM to fix the OS/2 linker.

The OS/2 system linker is maintained by IBM.


> > localcharset.c:
> > Moved most of the OS/2 specific code to os2compat.c.
> 
> Nope. localcharset.c is used in other GNU packages as well, and they
> don't have and don't want to have an os2compat.c.

Personally, I don't care where the OS/2 compatibility stuff is stored.
If you want to distribute it over all files, fine. If you want to
collect it in os2compat.c, fine, too. If you say the OS/2 specific
code (or most of it) won't be included into other packages then
I say other packages' libintl won't work for OS/2.


> > Try to find out the current OS/2 charset. If that's not possible
> > use the default code for non Win32 systems.
> > Use a more general function to strcmp() the codeset with the
> > existing aliases. In this case e.g. "de_DE" (the usual LANG
> > for Germany) is identical with the first string that contains
> > "de_DE" (which is "de_DE.ISO-8859-1"). Otherwise no correct
> > codeset is selected due to the entries in charset.alias.
> 
> If charset.alias does not contain a given locale name, then the first
> thing to consider is: a user error. On a system without built-in
> locales, tell the user to set LANG=de_DE.ISO-8859-1. If FreeBSD users
> can do that, OS/2 users can do it as well.  If you don't agree with
> this, then add the missing locale names to config.charset - in the
> OS/2 specific part, of course.

Okay, I'll do that.


Bye,
Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]