Web language codes

Web language codes

[Riley Williams]

Hi all.

I have just added Functions/languages.php to the elksweb2 CVS
tree. This is a translation list translating the codes used for
various languages into the English names for those languages,
implemented as a PHP declaration of an array called $language
and ready for use by those wishing to add definitions for any
other web pages.

At least, I *HOPE* this is valid PHP code. It is based on the
code in Functions/data.php but I have to admit that I'm nowhere
near being an expert on PHP so I could easily have made some
serious mistake in creating this page. Any advice appreciated.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18-Jul-2003

ELKS Development/FAQ Questions

[Phil Goembel]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

Ok. I'd like to help with the ELKS website, and with the 
documentation.

But my main interest is to help with development of the ELKS
code.

I have virtually no experience with the Linux development
environment, but I do have experience in cross-development
for embedded microprocessor systems (in DOS and Win32
environments)

I am trying to follow the FAQ in setting up the environment
so that I can compile the ELKS kernel, but have almost
immediately run into a problem.

The FAQ is telling me to install the Dev86 package in the
root (/) directory. I don't want to do this, and I see no 
reason that I should have to.

I would much rather do all of my cross development in
my home directory, with my standard user privileges, not
root privileges. I feel this would be much safer, especially
since I already have some tools installed that have the same
name as the Dev86 tools. I don't know where they came from,
and I'd rather not clobber them.

Is it possible to set up everything in ~/? If so, how
is it done? What reasons are there for me NOT to do it that 
way? If I can't set up everything in ~/, please explain why?

I will gladly update the ELKS FAQ with any answers you can 
give me.

Respectfully,
Phil

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ELKS Development/FAQ Questions

[Riley Williams]

Hi Phil.

 > Ok. I'd like to help with the ELKS website, and with the
 > documentation. But my main interest is to help with
 > development of the ELKS code.
 >
 > I have virtually no experience with the Linux development
 > environment, but I do have experience in cross-development
 > for embedded microprocessor systems (in DOS and Win32
 > environments)

You need to remember here that the tools used for ELKS are of
no use for Linux even though they are for the same processor.
This is because ELKS only uses the x86 processors in what is
called "Real Mode" since the 8086 that ELKS is primarily aimed
at has no other mode, whereas Linux uses it exclusively in
"386 Protected Mode" and, whilst the actual opcodes are mainly
the same, the environment they are used in, and the assumptions
the tools need to make, are completely different.

 > I am trying to follow the FAQ in setting up the environment
 > so that I can compile the ELKS kernel, but have almost
 > immediately run into a problem.
 >
 > The FAQ is telling me to install the Dev86 package in the
 > root (/) directory. I don't want to do this, and I see no
 > reason that I should have to.
 >
 > I would much rather do all of my cross development in my
 > home directory, with my standard user privileges, not root
 > privileges. I feel this would be much safer, especially
 > since I already have some tools installed that have the same
 > name as the Dev86 tools. I don't know where they came from,
 > and I'd rather not clobber them.

Have you ever installed the bin86 package? If so, that's an old
version of the dev86 package, and installing the dev86 package
will just install more recent versions of all of the same tools.

The Linux C compiler is "gcc" and the associated assembler and
loader are "as" and "ld" respectively. The ELKS compiler is "bcc"
and its associated assembler and loader are "as86" and "ld86"
respectively. As a result, it is not possible to interfere with
one by upgrading the tools associated with the other.

 > Is it possible to set up everything in ~/? If so, how
 > is it done? What reasons are there for me NOT to do it that
 > way? If I can't set up everything in ~/, please explain why?

From a purely practical viewpoint, as long as the relevant tools
are in a directory in the PATH environment variable, and no
earlier directory in that variable contains tools with the same
name, it doesn't actually matter where they are. However, it is
NOT a good idea to put a user directory ahead of the system
binary directory.

The standard place to put personal binaries is in the directory
~/bin with the same directory appended to the END of the standard
PATH variable with an entry of...

	if [ -d ~/bin ]; then
		export PATH=${PATH}:~/bin
	fi

...in your ~/.bashrc file. This ensures that the said directory
is only added if it actually existed when you logged on.

 > I will gladly update the ELKS FAQ with any answers you can 
 > give me.

Hopefully, the above will help you.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003

Re: ELKS Development/FAQ Questions

[Raghavan]

Phil,

I got the dev86 sources (dev86-0.16.1 ), built it and installed it in my
Home directory as a part of making ELKS 1.1

I installed it in ~/ELKS/my_install directory. I had to mention that this
was where I wanted to install in my Makefile ( or one of its related config
file ) while building the dev86.
The, I did a  'make install'.

After that , I  tweaked PATH as follows to make it see my bcc before the
system'c bcc which was there in /usr/bin or /usr/local/bin..

PATH=$HOME/ELKS/my_install/bin:$PATH

After that I built ELKS , It just worked fine. No Issues at all.

bye,
rags

----- Original Message -----
From: "Riley Williams" <Riley@Williams.Name>
To: "Phil Goembel" <phil-goembel@wi.rr.com>; "Linux ELKS"
<Linux-8086@vger.kernel.org>
Sent: Thursday, July 31, 2003 11:31 AM
Subject: Re: ELKS Development/FAQ Questions


> Hi Phil.
>
>  > Ok. I'd like to help with the ELKS website, and with the
>  > documentation. But my main interest is to help with
>  > development of the ELKS code.
>  >
>  > I have virtually no experience with the Linux development
>  > environment, but I do have experience in cross-development
>  > for embedded microprocessor systems (in DOS and Win32
>  > environments)
>
> You need to remember here that the tools used for ELKS are of
> no use for Linux even though they are for the same processor.
> This is because ELKS only uses the x86 processors in what is
> called "Real Mode" since the 8086 that ELKS is primarily aimed
> at has no other mode, whereas Linux uses it exclusively in
> "386 Protected Mode" and, whilst the actual opcodes are mainly
> the same, the environment they are used in, and the assumptions
> the tools need to make, are completely different.
>
>  > I am trying to follow the FAQ in setting up the environment
>  > so that I can compile the ELKS kernel, but have almost
>  > immediately run into a problem.
>  >
>  > The FAQ is telling me to install the Dev86 package in the
>  > root (/) directory. I don't want to do this, and I see no
>  > reason that I should have to.
>  >
>  > I would much rather do all of my cross development in my
>  > home directory, with my standard user privileges, not root
>  > privileges. I feel this would be much safer, especially
>  > since I already have some tools installed that have the same
>  > name as the Dev86 tools. I don't know where they came from,
>  > and I'd rather not clobber them.
>
> Have you ever installed the bin86 package? If so, that's an old
> version of the dev86 package, and installing the dev86 package
> will just install more recent versions of all of the same tools.
>
> The Linux C compiler is "gcc" and the associated assembler and
> loader are "as" and "ld" respectively. The ELKS compiler is "bcc"
> and its associated assembler and loader are "as86" and "ld86"
> respectively. As a result, it is not possible to interfere with
> one by upgrading the tools associated with the other.
>
>  > Is it possible to set up everything in ~/? If so, how
>  > is it done? What reasons are there for me NOT to do it that
>  > way? If I can't set up everything in ~/, please explain why?
>
> From a purely practical viewpoint, as long as the relevant tools
> are in a directory in the PATH environment variable, and no
> earlier directory in that variable contains tools with the same
> name, it doesn't actually matter where they are. However, it is
> NOT a good idea to put a user directory ahead of the system
> binary directory.
>
> The standard place to put personal binaries is in the directory
> ~/bin with the same directory appended to the END of the standard
> PATH variable with an entry of...
>
> if [ -d ~/bin ]; then
> export PATH=${PATH}:~/bin
> fi
>
> ...in your ~/.bashrc file. This ensures that the said directory
> is only added if it actually existed when you logged on.
>
>  > I will gladly update the ELKS FAQ with any answers you can
>  > give me.
>
> Hopefully, the above will help you.
>
> Best wishes from Riley.
> ---
>  * Nothing as pretty as a smile, nothing as ugly as a frown.
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ELKS Development/FAQ Questions

[Phil Goembel]

[-- Attachment #1: Type: text/plain, Size: 5622 bytes --]

Raghavan and Riley,

Thanks to both of you for responding to my questions. I will
start thinking of the best way to add this information to the ELKS
website. Of course I will make sure it's not already there, since
I seem to have a knack for reading the documentation two or three
times before finding what I'm looking for.

Be prepared for more questions shortly.

What I need right now, I think, is for one of the ELKS SourceForge
project administrators to give me developer access to at least the
website part of the CVS archive. My SourceForge username is pgoembel.

Raghavan and Riley for On Thu, 2003-07-31 at 04:56, Raghavan wrote:
> Phil,
> 
> I got the dev86 sources (dev86-0.16.1 ), built it and installed it in my
> Home directory as a part of making ELKS 1.1
> 
> I installed it in ~/ELKS/my_install directory. I had to mention that this
> was where I wanted to install in my Makefile ( or one of its related config
> file ) while building the dev86.
> The, I did a  'make install'.
> 
> After that , I  tweaked PATH as follows to make it see my bcc before the
> system'c bcc which was there in /usr/bin or /usr/local/bin..
> 
> PATH=$HOME/ELKS/my_install/bin:$PATH
> 
> After that I built ELKS , It just worked fine. No Issues at all.
> 
> bye,
> rags
> 
> ----- Original Message -----
> From: "Riley Williams" <Riley@Williams.Name>
> To: "Phil Goembel" <phil-goembel@wi.rr.com>; "Linux ELKS"
> <Linux-8086@vger.kernel.org>
> Sent: Thursday, July 31, 2003 11:31 AM
> Subject: Re: ELKS Development/FAQ Questions
> 
> 
> > Hi Phil.
> >
> >  > Ok. I'd like to help with the ELKS website, and with the
> >  > documentation. But my main interest is to help with
> >  > development of the ELKS code.
> >  >
> >  > I have virtually no experience with the Linux development
> >  > environment, but I do have experience in cross-development
> >  > for embedded microprocessor systems (in DOS and Win32
> >  > environments)
> >
> > You need to remember here that the tools used for ELKS are of
> > no use for Linux even though they are for the same processor.
> > This is because ELKS only uses the x86 processors in what is
> > called "Real Mode" since the 8086 that ELKS is primarily aimed
> > at has no other mode, whereas Linux uses it exclusively in
> > "386 Protected Mode" and, whilst the actual opcodes are mainly
> > the same, the environment they are used in, and the assumptions
> > the tools need to make, are completely different.
> >
> >  > I am trying to follow the FAQ in setting up the environment
> >  > so that I can compile the ELKS kernel, but have almost
> >  > immediately run into a problem.
> >  >
> >  > The FAQ is telling me to install the Dev86 package in the
> >  > root (/) directory. I don't want to do this, and I see no
> >  > reason that I should have to.
> >  >
> >  > I would much rather do all of my cross development in my
> >  > home directory, with my standard user privileges, not root
> >  > privileges. I feel this would be much safer, especially
> >  > since I already have some tools installed that have the same
> >  > name as the Dev86 tools. I don't know where they came from,
> >  > and I'd rather not clobber them.
> >
> > Have you ever installed the bin86 package? If so, that's an old
> > version of the dev86 package, and installing the dev86 package
> > will just install more recent versions of all of the same tools.
> >
> > The Linux C compiler is "gcc" and the associated assembler and
> > loader are "as" and "ld" respectively. The ELKS compiler is "bcc"
> > and its associated assembler and loader are "as86" and "ld86"
> > respectively. As a result, it is not possible to interfere with
> > one by upgrading the tools associated with the other.
> >
> >  > Is it possible to set up everything in ~/? If so, how
> >  > is it done? What reasons are there for me NOT to do it that
> >  > way? If I can't set up everything in ~/, please explain why?
> >
> > From a purely practical viewpoint, as long as the relevant tools
> > are in a directory in the PATH environment variable, and no
> > earlier directory in that variable contains tools with the same
> > name, it doesn't actually matter where they are. However, it is
> > NOT a good idea to put a user directory ahead of the system
> > binary directory.
> >
> > The standard place to put personal binaries is in the directory
> > ~/bin with the same directory appended to the END of the standard
> > PATH variable with an entry of...
> >
> > if [ -d ~/bin ]; then
> > export PATH=${PATH}:~/bin
> > fi
> >
> > ...in your ~/.bashrc file. This ensures that the said directory
> > is only added if it actually existed when you logged on.
> >
> >  > I will gladly update the ELKS FAQ with any answers you can
> >  > give me.
> >
> > Hopefully, the above will help you.
> >
> > Best wishes from Riley.
> > ---
> >  * Nothing as pretty as a smile, nothing as ugly as a frown.
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ELKS Development/FAQ Questions

[Paul Nasrat]

On Thu, Jul 31, 2003 at 04:30:51PM -0500, Phil Goembel wrote:
 
> What I need right now, I think, is for one of the ELKS SourceForge
> project administrators to give me developer access to at least the
> website part of the CVS archive. My SourceForge username is pgoembel.

You can check out from pserver and submit patches - that's usually a
good start.

It's the elksweb module.

CVSROOT=:pserver:anonymous@cvs.elks.sf.net:/cvsroot/elks

It's a day behind but elks isn't really a moving target :)

Paul

Re: ELKS Development/FAQ Questions

[Phil Goembel]

[-- Attachment #1: Type: text/plain, Size: 5713 bytes --]

Hi again Riley,

Thanks for taking the time to reply.

On Thu, 2003-07-31 at 01:01, Riley Williams wrote:
> Hi Phil.
> 
>  > Ok. I'd like to help with the ELKS website, and with the
>  > documentation. But my main interest is to help with
>  > development of the ELKS code.
>  >
>  > I have virtually no experience with the Linux development
>  > environment, but I do have experience in cross-development
>  > for embedded microprocessor systems (in DOS and Win32
>  > environments)
> 
> You need to remember here that the tools used for ELKS are of
> no use for Linux even though they are for the same processor.
> This is because ELKS only uses the x86 processors in what is
> called "Real Mode" since the 8086 that ELKS is primarily aimed
> at has no other mode, whereas Linux uses it exclusively in
> "386 Protected Mode" and, whilst the actual opcodes are mainly
> the same, the environment they are used in, and the assumptions
> the tools need to make, are completely different.
> 
I understand the difference between "Real" mode and "Protected"
mode. That is one reason why I have some reservations about mixing
"Real" mode development tools into the same directories as the native
"Protected" mode tools and libraries.

But, as I have seen from recent posts to the ELKS list, it might
be worthwhile to add this to the FAQ. I am also also thinking it 
might be helpful to explain why programming for the x86 "Real" mode 
is so different from programming for other MMU-less architectures
(like the "Dragonball", e.g.). 

>  > I am trying to follow the FAQ in setting up the environment
>  > so that I can compile the ELKS kernel, but have almost
>  > immediately run into a problem.
>  >
>  > The FAQ is telling me to install the Dev86 package in the
>  > root (/) directory. I don't want to do this, and I see no
>  > reason that I should have to.
>  >
>  > I would much rather do all of my cross development in my
>  > home directory, with my standard user privileges, not root
>  > privileges. I feel this would be much safer, especially
>  > since I already have some tools installed that have the same
>  > name as the Dev86 tools. I don't know where they came from,
>  > and I'd rather not clobber them.
> 
> Have you ever installed the bin86 package? If so, that's an old
> version of the dev86 package, and installing the dev86 package
> will just install more recent versions of all of the same tools.
> 

Actually, I appear to have dev86-0.15.5 installed. Looks like I
installed it as an RPM package about 2 years ago. Is this version 
too old? 

Is there an RPM package for the latest version?

If not, would there be any interest in having one? 

I have created some simple RPM packages before, and am also intent on
learning how to create Debian packages (when I said I'm "virtually
ignorant" above, I was referring to setting up and troubleshooting
problems in a GNU tool-chain - I'm usually at a complete loss when
things like "make configure", "make dep", and "make" start spewing out
errors).

> The Linux C compiler is "gcc" and the associated assembler and
> loader are "as" and "ld" respectively. The ELKS compiler is "bcc"
> and its associated assembler and loader are "as86" and "ld86"
> respectively. As a result, it is not possible to interfere with
> one by upgrading the tools associated with the other.
> 
>  > Is it possible to set up everything in ~/? If so, how
>  > is it done? What reasons are there for me NOT to do it that
>  > way? If I can't set up everything in ~/, please explain why?
> 
> >From a purely practical viewpoint, as long as the relevant tools
> are in a directory in the PATH environment variable, and no
> earlier directory in that variable contains tools with the same
> name, it doesn't actually matter where they are. However, it is
> NOT a good idea to put a user directory ahead of the system
> binary directory.
> 

I've read before that it is a bad idea to put a user directory
ahead of the system binary directories, but never an explanation. 
Why is this a bad idea?

Does it have something to do with the possibility of a malicious
third-party placing trojans in the user's directories with the same name
as a system binary?

One of my reasons for wanting to install the tools in my user
directory was because I thought that it would be safer than
installing code of uncertain origin in the system binary directories.
I don't like using root privileges if I don't have to, but I can
change my habits if there are compelling reasons to do so.

> The standard place to put personal binaries is in the directory
> ~/bin with the same directory appended to the END of the standard
> PATH variable with an entry of...
> 
> 	if [ -d ~/bin ]; then
> 		export PATH=${PATH}:~/bin
> 	fi
> 
> ...in your ~/.bashrc file. This ensures that the said directory
> is only added if it actually existed when you logged on.
> 

My plan was to have a script to set up a different development
environment (tool chain) depending what project I wish to
work on. Then I normally would not have ~/bin in my PATH
except in the one terminal window I'm using for builds.
Or maybe, once I understand the GNU toolchain better, I
will set things up so that "make configure" or "./configure"
will set up macros with the correct paths for each tool?

>  > I will gladly update the ELKS FAQ with any answers you can 
>  > give me.
> 
> Hopefully, the above will help you.
> 
> Best wishes from Riley.
> ---
>  * Nothing as pretty as a smile, nothing as ugly as a frown.

Everything you've provided has been a help. Thank you.

Regards,
Phil

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ELKS Development/FAQ Questions

[Phil Goembel]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Hi Rags,

Thank you. This is what I want to do. I will take a look at the
Makefile for dev86 to see how to specify the install directory.
I assume I will have to do one or more of these things:
  a. edit the Makefile, 
  b. set an environment variable,
  c. or pass an argument to the make command
Is that correct?

Regards,
Phil

On Thu, 2003-07-31 at 04:56, Raghavan wrote:
> Phil,
> 
> I got the dev86 sources (dev86-0.16.1 ), built it and installed it in my
> Home directory as a part of making ELKS 1.1
> 
> I installed it in ~/ELKS/my_install directory. I had to mention that this
> was where I wanted to install in my Makefile ( or one of its related config
> file ) while building the dev86.
> The, I did a  'make install'.
> 
> After that , I  tweaked PATH as follows to make it see my bcc before the
> system'c bcc which was there in /usr/bin or /usr/local/bin..
> 
> PATH=$HOME/ELKS/my_install/bin:$PATH
> 
> After that I built ELKS , It just worked fine. No Issues at all.
> 
> bye,
> rags
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: ELKS Development/FAQ Questions

[Riley Williams]

Hi Phil.

 > Thanks for taking the time to reply.

NP.

 >>> Ok. I'd like to help with the ELKS website, and with the
 >>> documentation. But my main interest is to help with
 >>> development of the ELKS code.
 >>>
 >>> I have virtually no experience with the Linux development
 >>> environment, but I do have experience in cross-development
 >>> for embedded microprocessor systems (in DOS and Win32
 >>> environments)

 >> You need to remember here that the tools used for ELKS are of
 >> no use for Linux even though they are for the same processor.
 >> This is because ELKS only uses the x86 processors in what is
 >> called "Real Mode" since the 8086 that ELKS is primarily aimed
 >> at has no other mode, whereas Linux uses it exclusively in
 >> "386 Protected Mode" and, whilst the actual opcodes are mainly
 >> the same, the environment they are used in, and the assumptions
 >> the tools need to make, are completely different.

 > I understand the difference between "Real" mode and "Protected"
 > mode. That is one reason why I have some reservations about
 > mixing "Real" mode development tools into the same directories
 > as the native "Protected" mode tools and libraries.

There's actually no reason to have reservations about that, as it's
no more of a problem than having the binaries for ftp and telnet in
the same directory - both are protocols used over the Internet, but
have major differences from each other.

 > But, as I have seen from recent posts to the ELKS list, it might
 > be worthwhile to add this to the FAQ. I am also thinking it might
 > be helpful to explain why programming for the x86 "Real" mode is
 > so different from programming for other MMU-less architectures
 > (like the "Dragonball", e.g.). 

There could certainly be reasons for adding a pointer to one of the
many excellent websites about the differences between the real and
protected modes on the x86 family of processors, but I can't see
any reason for rewriting what's already out there.

 >>> I am trying to follow the FAQ in setting up the environment
 >>> so that I can compile the ELKS kernel, but have almost
 >>> immediately run into a problem.
 >>>
 >>> The FAQ is telling me to install the Dev86 package in the
 >>> root (/) directory. I don't want to do this, and I see no
 >>> reason that I should have to.
 >>>
 >>> I would much rather do all of my cross development in my
 >>> home directory, with my standard user privileges, not root
 >>> privileges. I feel this would be much safer, especially
 >>> since I already have some tools installed that have the same
 >>> name as the Dev86 tools. I don't know where they came from,
 >>> and I'd rather not clobber them.

 >> Have you ever installed the bin86 package? If so, that's an old
 >> version of the dev86 package, and installing the dev86 package
 >> will just install more recent versions of all of the same tools.

 > Actually, I appear to have dev86-0.15.5 installed. Looks like I
 > installed it as an RPM package about 2 years ago. Is this version 
 > too old?

That's newer than the version I'm using - I show dev86-0.15.0-2 here,
a Red Hat Linux 6.2 based system with most updates already applied.

 > Is there an RPM package for the latest version?

I'm just checking ftp://updates.redhat.com/6.2/en/os/ to see whether
any updates show thereon - OK, none showing, so presumably nothing on
Red Hat's site. I'm not sure offhand where the dev86 development site
is, but there's almost certainly an RPM for the latest version there.

 > I have created some simple RPM packages before, and am also intent
 > on learning how to create Debian packages (when I said I'm "virtually
 > ignorant" above, I was referring to setting up and troubleshooting
 > problems in a GNU tool-chain - I'm usually at a complete loss when
 > things like "make configure", "make dep", and "make" start spewing
 > out errors).

That is understandable.

 >> The Linux C compiler is "gcc" and the associated assembler and
 >> loader are "as" and "ld" respectively. The ELKS compiler is "bcc"
 >> and its associated assembler and loader are "as86" and "ld86"
 >> respectively. As a result, it is not possible to interfere with
 >> one by upgrading the tools associated with the other.

 >>> Is it possible to set up everything in ~/? If so, how
 >>> is it done? What reasons are there for me NOT to do it that
 >>> way? If I can't set up everything in ~/, please explain why?

 >> From a purely practical viewpoint, as long as the relevant tools
 >> are in a directory in the PATH environment variable, and no
 >> earlier directory in that variable contains tools with the same
 >> name, it doesn't actually matter where they are. However, it is
 >> NOT a good idea to put a user directory ahead of the system
 >> binary directory.

 > I've read before that it is a bad idea to put a user directory
 > ahead of the system binary directories, but never an explanation.
 > Why is this a bad idea?
 >
 > Does it have something to do with the possibility of a malicious
 > third-party placing Trojans in the user's directories with the same
 > name as a system binary?

Not even that - simply as a result of ignorance, it's possible to create
a program with the same name as a standard program. If you have the PATH
with ./bin in front of the system directory with that standard command
in it, then ANY standard shell script that makes use of the said command
will accidentally use your version rather than the standard one.

As an example of how widespread this is, I just ran the following on
my development system...

	file /usr/bin/* | fgrep -iw script

...and found 285 shell scripts in that one system binary directory...

 > One of my reasons for wanting to install the tools in my user
 > directory was because I thought that it would be safer than
 > installing code of uncertain origin in the system binary directories.
 > I don't like using root privileges if I don't have to, but I can
 > change my habits if there are compelling reasons to do so.

As far as the dev86 package is concerned, the only reason to have more
than one copy of it installed on your system is if you are helping to
debug the existing version and create a new version.

 >> The standard place to put personal binaries is in the directory
 >> ~/bin with the same directory appended to the END of the standard
 >> PATH variable with an entry of...
 >> 
 >>	if [ -d ~/bin ]; then
 >>		export PATH=${PATH}:~/bin
 >>	fi
 >> 
 >> ...in your ~/.bashrc file. This ensures that the said directory
 >> is only added if it actually existed when you logged on.

 > My plan was to have a script to set up a different development
 > environment (tool chain) depending what project I wish to
 > work on. Then I normally would not have ~/bin in my PATH
 > except in the one terminal window I'm using for builds.
 > Or maybe, once I understand the GNU tool chain better, I
 > will set things up so that "make configure" or "./configure"
 > will set up macros with the correct paths for each tool?

I have to admit that sounds like a lot of work for next to no gain
to me, but you know your setup better than I ever can...

 >>> I will gladly update the ELKS FAQ with any answers you can 
 >>> give me.

 >> Hopefully, the above will help you.

 > Everything you've provided has been a help. Thank you.

Thanks for that.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003