Add search path to the cygwin.

Add search path to the cygwin.

[Fu, Jack]

Hi all:

Can anyone tell me how to add search path to the cygwin bash shell?  I tried
to use gcc to compile a simple program and it is looking for some header
files.  I tried to add path using $ $PATH=/cygnus/include:$PATH.  What is
the correct command?

Thanks
Jack

Re: Add search path to the cygwin.

[mike corbeil ordinary user account]

"Fu, Jack" wrote:
> 
> Hi all:
> 
> Can anyone tell me how to add search path to the cygwin bash shell?  I tried
> to use gcc to compile a simple program and it is looking for some header
> files.  I tried to add path using $ $PATH=/cygnus/include:$PATH.  What is
> the correct command?
> 
> Thanks
> Jack

Paths for include file directories usually aren't specified with $PATH,
but instead specified in the make input file, default name being
"Makefile"; or, as a command line argument to the make command, when you
invoke it.  

Read the man page on make, is the first place to start.

If, however, defining the path in $PATH is supposed to work for what
you're doing, then make sure to export PATH after modifying it's
definition.

      $PATH=/cygnus/include:$PATH
      export PATH

      or

      $PATH=$PATH:/cygnus/include
      export PATH

I had the latter problem last night when trying to build SmallEiffel; it
said to add SmallEiffel/sys/system.se to PATH, but forgot to mention to
say to also export PATH.  Doing that got rid of the remaining problem.

How you'd redefine PATH, e.g., inserting /cygnus/include as the first or
as the last directory, depends on your environment.  If there are files
in this directory which exist in other of your PATH directories and you
want to use the first one found, then put /cygnus/include at the end. 
If you want to use the /cygnus/include files, regardless of whether
there are files by the same name in other PATH directories, then put
/cygnus/include at the beginning of PATH.

However, if you're always going to use this directory when you're doing
what you're doing, then defining this in your make input file, or as a
command line argument to make, may be better, or just as good.  I think
it can be specified on the command line, but this may override what's
already defined in the make file, if there are includes defined there. 
(This is what happens with env variables in the Makefile and this may
also preclude the build from working.)  

I've always defined these and seen these defined in the make file.  I've
never seen PATH used to specify the location of include directories, but
PATH might work in your case (seems strange to me, though, i.e., for
include directories).

Question re. FSF GNU SmallEiffel vs. C and C++

[mike corbeil ordinary user account]

Does anyone know anything about the comparison or where valid and
authoritative information in this respect may be found?  

I know that there's a SmallEiffel email list or faq, however it'd be
nice to have authoritative information which is not so closely tied to
SmallEiffel, itself.

What I've read so far says that it, i.e., Eiffel, is about the best oopl
available, supposedly better than C++, and may be used instead of C, as
a better alternative to either of these.  

However, after building SmallEiffel last night and reading through some
of the documentation and other files, I learned that the SmallEiffel
compiler translates the code to or into C, followed (obv.) by compiling
the C code.  This seems tentatively or possibly okay, or even good, if
it avoids problems people have with C++, and C; however, this also means
that SmallEiffel is more of a macro language than a real one, albeit
modelled after or based on the Eiffel language.

Because SmallEiffel uses gcc as the default compiler, I thought this
question might possibly be okay to ask, here.

mcorbeil@netrevolution.com

Re: Question re. FSF GNU SmallEiffel vs. C and C++

[Alexandre Oliva]

On Oct 17, 2000, mike corbeil ordinary user account <mcorbeil@NetRevolution.com> wrote:

> the SmallEiffel compiler translates the code to or into C, followed
> (obv.) by compiling the C code.  This seems tentatively or possibly
> okay, or even good, if it avoids problems people have with C++, and
> C; however, this also means that SmallEiffel is more of a macro
> language than a real one, albeit modelled after or based on the
> Eiffel language.

This is not unlike the first implementation of C++, that was also a
translator from C++ to C.  Given enough time and interest, people may
eventually write a front-end for GCC, that may allow more higher-level
information about the source program to be exposed to the compiler,
providing for language-specific optimizations.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Question re. FSF GNU SmallEiffel vs. C and C++

[mike corbeil ordinary user account]

Alexandre Oliva wrote:
> 
> On Oct 17, 2000, mike corbeil ordinary user account <mcorbeil@NetRevolution.com> wrote:

Since I didn't get nailed in any way for posting the question to this
mailing list, I'll venture a little further, because I don't know that
you'd want this only sent direct to you.  The bit more follows your
respone.

> 
> > the SmallEiffel compiler translates the code to or into C, followed
> > (obv.) by compiling the C code.  This seems tentatively or possibly
> > okay, or even good, if it avoids problems people have with C++, and
> > C; however, this also means that SmallEiffel is more of a macro
> > language than a real one, albeit modelled after or based on the
> > Eiffel language.
> 
> This is not unlike the first implementation of C++, that was also a
> translator from C++ to C.  Given enough time and interest, people may
> eventually write a front-end for GCC, that may allow more higher-level
> information about the source program to be exposed to the compiler,
> providing for language-specific optimizations.

In other words, you're not saying that Eiffel or SmallEiffel is
something you're against, based on your experience and knowledge, if I
understand you correctly.

I found some material to read last night (I have a book from several
years ago, but it's not within reach) and from the albeit small amount
of actual Eiffel language used to highlight certain aspects or strengths
of the language, it looks interesting.  

I've taken an OOP course using C++, read a few or more reputable books,
and worked for a few months with it; however, having read several months
ago that Eiffel was considered better, I'm wondering which to focus on
for some self-study and subsequently trying to find employment.  

I have around ten years experience, mostly on Unix, with "enough" C and
shell scripting, database and gui development, PASCAL (years ago), some
FORTRAN, ..., and a b.sc. CS (swe).  With all of the importation of
foreign labor, I'm in need of  taking some time to learn Linux, Perl
(these two, I've been working on for about six months), and would like
to get some good compiled language in the mix.

Even if I've already more than broken the ice with C++, I've heard or
read that many people or projects have problems with it, and the little
I've read about Eiffel makes it sound like a good way to go.  There
aren't presently many jobs for this, but there are a few or more
companies which are apparently using it.  If it is as good as what I've
read, then I may have some chance of getting future clients (or
employers) to accept using Eiffel, especially since it's a "front-end"
to C and makes C programs better (supposedly anyway).

The fact that it does compile to C, they're working on improving the
compile to Java bytecode (which SmallEiffel already has some of), and
"hooks" to C and (I believe) C++ are supported, well, this makes Eiffel
seem of value (but I'm not sure).  Someone from Lockheed, a guru or a
manager (or both), supposedly recommends Eiffel over Ada95, and from
what I read, it's only a little slower than normal C and C++ binaries,
due to assertions.  The expressiveness looks, at least initially,
interesting, and I like focusing on providing good and "clean"
solutions.

However, I don't have personal acquaintances who know anything about
Eiffel; therefore, I've only the little reading for a basis.  The
documents I've read on Eiffel speak more highly of Java compared to C++,
and don't seem to make a whole lot of the difference between Eiffel vs.
Java, but do say that Eiffel is better in some supposedly important ways
(I don't remember exactly which these are).  I only know of Java being
used for internet/intranet/web, my background is systems programming,
and I haven't been planning on becoming a web developer, not per se
anyway (if I got hired for that, then ...).

Having C for experience and Eiffel compiling to C, with many companies
using GCC, seems a potential plus.

I think that I'm satisfied with it compiling to C, after last night's
reading.  Using Eiffel may be or is a way of providing more reliable C
code, and with C being considered an object-based language, good for
component oriented development, the extra or robust data typing of
Eiffel makes it, again, seem probably worthwhile.

Linux and Perl, alone, with my prior experience, should open doors of
opportunity, but I'd like to learn more OOA/OOD/OOP with a compiled
language.  Java would be an option, and I wouldn't mind Smalltalk, but
I'm in the world of fuzzy logic at the moment, evidently.

This, hopefully, isn't too long and not too out of place for this
mailing list, however do you have any further tips or feedback to share
based on this additional gibberish?  It'd be appreciated, if you have
any.

P.S.  I don't really care whether work is in FORTRAN, C, C++, ... for
the primary focus is to do the best that can be done with which ever
language is pertinent to a job.  For new development, providing the
best, or at least a very good, solution, one that's easy to understand,
maintain, and reliable, is the way (in case this is of any help in
understanding where I'm "coming from").  (Sorry for the length.)


> 
> --
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me

RE: Question re. FSF GNU SmallEiffel vs. C and C++

[Saran]

From what I understand about Eiffel when I was studying it in University, is
that this language is more robust in certain aspects like strong
assertions(pre- and post-), no pointers(doesn't allow the programmer to
manipulate pointers directly), type checking, etc.  This means that there is
less likelyhood of programs corrupting data or overwriting information in
memory, etc.  The ESA (European Space Agency) uses Eiffel for their
programs.  In short, this language was designed so that you don't screw up
and destroy a multi-billion dollar project due to a small error in your
data.

The thing that I'd like to stress is that Eiffel is actually an evolution in
to a programming language.  It started off as a methodology for programming
or something like that, and then evolved in to a programming language of its
own right.  It is not in fact a front end language.  The reason that the
implementors of the language chose to convert the code into C or C++ is for
performance reasons, as compilers for C and C++ at that time was very
efficient as well as fast execution code;  it is able to interface with a
multitude of other languages; and furthermore C or C++ is a mainstay for
UNIX systems.

If you ask me what I think about Java, I'd say that it is a hyped up
language that is useful for only one thing, which is flashy moving graphics.
It is basically useless for anything else other than online internet
applications which are slow and basically a reinvention of the wheel (A
C/C++ wannabe).  The only good thing going for Java is the multiplatform
use, which I think is not that great at all.  Don't even bother comparing
Eiffel to Java or even C/C++ for that matter, as these languages were
designed for different applications.

Ok, this is just my point of view on things, so don't start flaming me.

Cheers,
Saran.



-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [ mailto:gcc-help-owner@gcc.gnu.org]On
Behalf Of mike corbeil ordinary user account
Sent: Wednesday, October 18, 2000 10:35 PM
To: 'gcc-help@gcc.gnu.org'
Subject: Re: Question re. FSF GNU SmallEiffel vs. C and C++


Alexandre Oliva wrote:
>
> On Oct 17, 2000, mike corbeil ordinary user account
<mcorbeil@NetRevolution.com> wrote:

Since I didn't get nailed in any way for posting the question to this
mailing list, I'll venture a little further, because I don't know that
you'd want this only sent direct to you.  The bit more follows your
respone.

>
> > the SmallEiffel compiler translates the code to or into C, followed
> > (obv.) by compiling the C code.  This seems tentatively or possibly
> > okay, or even good, if it avoids problems people have with C++, and
> > C; however, this also means that SmallEiffel is more of a macro
> > language than a real one, albeit modelled after or based on the
> > Eiffel language.
>
> This is not unlike the first implementation of C++, that was also a
> translator from C++ to C.  Given enough time and interest, people may
> eventually write a front-end for GCC, that may allow more higher-level
> information about the source program to be exposed to the compiler,
> providing for language-specific optimizations.

In other words, you're not saying that Eiffel or SmallEiffel is
something you're against, based on your experience and knowledge, if I
understand you correctly.

I found some material to read last night (I have a book from several
years ago, but it's not within reach) and from the albeit small amount
of actual Eiffel language used to highlight certain aspects or strengths
of the language, it looks interesting.

I've taken an OOP course using C++, read a few or more reputable books,
and worked for a few months with it; however, having read several months
ago that Eiffel was considered better, I'm wondering which to focus on
for some self-study and subsequently trying to find employment.

I have around ten years experience, mostly on Unix, with "enough" C and
shell scripting, database and gui development, PASCAL (years ago), some
FORTRAN, ..., and a b.sc. CS (swe).  With all of the importation of
foreign labor, I'm in need of  taking some time to learn Linux, Perl
(these two, I've been working on for about six months), and would like
to get some good compiled language in the mix.

Even if I've already more than broken the ice with C++, I've heard or
read that many people or projects have problems with it, and the little
I've read about Eiffel makes it sound like a good way to go.  There
aren't presently many jobs for this, but there are a few or more
companies which are apparently using it.  If it is as good as what I've
read, then I may have some chance of getting future clients (or
employers) to accept using Eiffel, especially since it's a "front-end"
to C and makes C programs better (supposedly anyway).

The fact that it does compile to C, they're working on improving the
compile to Java bytecode (which SmallEiffel already has some of), and
"hooks" to C and (I believe) C++ are supported, well, this makes Eiffel
seem of value (but I'm not sure).  Someone from Lockheed, a guru or a
manager (or both), supposedly recommends Eiffel over Ada95, and from
what I read, it's only a little slower than normal C and C++ binaries,
due to assertions.  The expressiveness looks, at least initially,
interesting, and I like focusing on providing good and "clean"
solutions.

However, I don't have personal acquaintances who know anything about
Eiffel; therefore, I've only the little reading for a basis.  The
documents I've read on Eiffel speak more highly of Java compared to C++,
and don't seem to make a whole lot of the difference between Eiffel vs.
Java, but do say that Eiffel is better in some supposedly important ways
(I don't remember exactly which these are).  I only know of Java being
used for internet/intranet/web, my background is systems programming,
and I haven't been planning on becoming a web developer, not per se
anyway (if I got hired for that, then ...).

Having C for experience and Eiffel compiling to C, with many companies
using GCC, seems a potential plus.

I think that I'm satisfied with it compiling to C, after last night's
reading.  Using Eiffel may be or is a way of providing more reliable C
code, and with C being considered an object-based language, good for
component oriented development, the extra or robust data typing of
Eiffel makes it, again, seem probably worthwhile.

Linux and Perl, alone, with my prior experience, should open doors of
opportunity, but I'd like to learn more OOA/OOD/OOP with a compiled
language.  Java would be an option, and I wouldn't mind Smalltalk, but
I'm in the world of fuzzy logic at the moment, evidently.

This, hopefully, isn't too long and not too out of place for this
mailing list, however do you have any further tips or feedback to share
based on this additional gibberish?  It'd be appreciated, if you have
any.

P.S.  I don't really care whether work is in FORTRAN, C, C++, ... for
the primary focus is to do the best that can be done with which ever
language is pertinent to a job.  For new development, providing the
best, or at least a very good, solution, one that's easy to understand,
maintain, and reliable, is the way (in case this is of any help in
understanding where I'm "coming from").  (Sorry for the length.)


>
> --
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Question re. FSF GNU SmallEiffel vs. C and C++

[mike corbeil ordinary user account]

Thanks Saran.  I appreciate the response, but won't say more, to avoid
wasting the time of members of this mailing list.  If others want to
continue enlightening the world, then I'll gladly read.


Saran wrote:
> 
> >From what I understand about Eiffel when I was studying it in University, is
> that this language is more robust in certain aspects like strong
> assertions(pre- and post-), no pointers(doesn't allow the programmer to
> manipulate pointers directly), type checking, etc.  This means that there is
> less likelyhood of programs corrupting data or overwriting information in
> memory, etc.  The ESA (European Space Agency) uses Eiffel for their
> programs.  In short, this language was designed so that you don't screw up
> and destroy a multi-billion dollar project due to a small error in your
> data.
> 
> The thing that I'd like to stress is that Eiffel is actually an evolution in
> to a programming language.  It started off as a methodology for programming
> or something like that, and then evolved in to a programming language of its
> own right.  It is not in fact a front end language.  The reason that the
> implementors of the language chose to convert the code into C or C++ is for
> performance reasons, as compilers for C and C++ at that time was very
> efficient as well as fast execution code;  it is able to interface with a
> multitude of other languages; and furthermore C or C++ is a mainstay for
> UNIX systems.
> 
> If you ask me what I think about Java, I'd say that it is a hyped up
> language that is useful for only one thing, which is flashy moving graphics.
> It is basically useless for anything else other than online internet
> applications which are slow and basically a reinvention of the wheel (A
> C/C++ wannabe).  The only good thing going for Java is the multiplatform
> use, which I think is not that great at all.  Don't even bother comparing
> Eiffel to Java or even C/C++ for that matter, as these languages were
> designed for different applications.
> 
> Ok, this is just my point of view on things, so don't start flaming me.
> 
> Cheers,
> Saran.
> 
> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [ mailto:gcc-help-owner@gcc.gnu.org]On
> Behalf Of mike corbeil ordinary user account
> Sent: Wednesday, October 18, 2000 10:35 PM
> To: 'gcc-help@gcc.gnu.org'
> Subject: Re: Question re. FSF GNU SmallEiffel vs. C and C++
> 
> Alexandre Oliva wrote:
> >
> > On Oct 17, 2000, mike corbeil ordinary user account
> <mcorbeil@NetRevolution.com> wrote:
> 
> Since I didn't get nailed in any way for posting the question to this
> mailing list, I'll venture a little further, because I don't know that
> you'd want this only sent direct to you.  The bit more follows your
> respone.
> 
> >
> > > the SmallEiffel compiler translates the code to or into C, followed
> > > (obv.) by compiling the C code.  This seems tentatively or possibly
> > > okay, or even good, if it avoids problems people have with C++, and
> > > C; however, this also means that SmallEiffel is more of a macro
> > > language than a real one, albeit modelled after or based on the
> > > Eiffel language.
> >
> > This is not unlike the first implementation of C++, that was also a
> > translator from C++ to C.  Given enough time and interest, people may
> > eventually write a front-end for GCC, that may allow more higher-level
> > information about the source program to be exposed to the compiler,
> > providing for language-specific optimizations.
> 
> In other words, you're not saying that Eiffel or SmallEiffel is
> something you're against, based on your experience and knowledge, if I
> understand you correctly.
> 
> I found some material to read last night (I have a book from several
> years ago, but it's not within reach) and from the albeit small amount
> of actual Eiffel language used to highlight certain aspects or strengths
> of the language, it looks interesting.
> 
> I've taken an OOP course using C++, read a few or more reputable books,
> and worked for a few months with it; however, having read several months
> ago that Eiffel was considered better, I'm wondering which to focus on
> for some self-study and subsequently trying to find employment.
> 
> I have around ten years experience, mostly on Unix, with "enough" C and
> shell scripting, database and gui development, PASCAL (years ago), some
> FORTRAN, ..., and a b.sc. CS (swe).  With all of the importation of
> foreign labor, I'm in need of  taking some time to learn Linux, Perl
> (these two, I've been working on for about six months), and would like
> to get some good compiled language in the mix.
> 
> Even if I've already more than broken the ice with C++, I've heard or
> read that many people or projects have problems with it, and the little
> I've read about Eiffel makes it sound like a good way to go.  There
> aren't presently many jobs for this, but there are a few or more
> companies which are apparently using it.  If it is as good as what I've
> read, then I may have some chance of getting future clients (or
> employers) to accept using Eiffel, especially since it's a "front-end"
> to C and makes C programs better (supposedly anyway).
> 
> The fact that it does compile to C, they're working on improving the
> compile to Java bytecode (which SmallEiffel already has some of), and
> "hooks" to C and (I believe) C++ are supported, well, this makes Eiffel
> seem of value (but I'm not sure).  Someone from Lockheed, a guru or a
> manager (or both), supposedly recommends Eiffel over Ada95, and from
> what I read, it's only a little slower than normal C and C++ binaries,
> due to assertions.  The expressiveness looks, at least initially,
> interesting, and I like focusing on providing good and "clean"
> solutions.
> 
> However, I don't have personal acquaintances who know anything about
> Eiffel; therefore, I've only the little reading for a basis.  The
> documents I've read on Eiffel speak more highly of Java compared to C++,
> and don't seem to make a whole lot of the difference between Eiffel vs.
> Java, but do say that Eiffel is better in some supposedly important ways
> (I don't remember exactly which these are).  I only know of Java being
> used for internet/intranet/web, my background is systems programming,
> and I haven't been planning on becoming a web developer, not per se
> anyway (if I got hired for that, then ...).
> 
> Having C for experience and Eiffel compiling to C, with many companies
> using GCC, seems a potential plus.
> 
> I think that I'm satisfied with it compiling to C, after last night's
> reading.  Using Eiffel may be or is a way of providing more reliable C
> code, and with C being considered an object-based language, good for
> component oriented development, the extra or robust data typing of
> Eiffel makes it, again, seem probably worthwhile.
> 
> Linux and Perl, alone, with my prior experience, should open doors of
> opportunity, but I'd like to learn more OOA/OOD/OOP with a compiled
> language.  Java would be an option, and I wouldn't mind Smalltalk, but
> I'm in the world of fuzzy logic at the moment, evidently.
> 
> This, hopefully, isn't too long and not too out of place for this
> mailing list, however do you have any further tips or feedback to share
> based on this additional gibberish?  It'd be appreciated, if you have
> any.
> 
> P.S.  I don't really care whether work is in FORTRAN, C, C++, ... for
> the primary focus is to do the best that can be done with which ever
> language is pertinent to a job.  For new development, providing the
> best, or at least a very good, solution, one that's easy to understand,
> maintain, and reliable, is the way (in case this is of any help in
> understanding where I'm "coming from").  (Sorry for the length.)
> 
> >
> > --
> > Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> > Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> > CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> > Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Add search path to the cygwin.

[Alexandre Oliva]

On Oct 17, 2000, "Fu, Jack" <JFu@NETsilicon.com> wrote:

> it is looking for some header files.  I tried to add path using $
> $PATH=/cygnus/include:$PATH.

Use the command-line switch `-I/directory/name'.  If you really want
an environment variable, the GCC manual mentions C_INCLUDE_PATH,
CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

RE: Add search path to the cygwin.

[David Korn]

>"Fu, Jack" wrote:
>>
>> I tried to add path using $ $PATH=/cygnus/include:$PATH.

>From: mike corbeil ordinary user account [ mailto:mcorbeil@NetRevolution.com ]

>      $PATH=/cygnus/include:$PATH
>      export PATH
>
>      or
>
>      $PATH=$PATH:/cygnus/include
>      export PATH

  PMFBI, but.... surely you mean

       PATH=/cygnus/include:$PATH
       export PATH

 because if you put that first $ sign there, it expands the path, rather
than treating it as a variable name, so if (for example) your path used to
be /usr/bin:/bin, then what you've just typed to bash (after expansion) is

   /usr/bin:/bin=/cygnus/include:/usr/bin:/bin

which of course doesn't make a lot of sense to bash...

    hth,
        DaveK
-- 
 "The secret of life is honesty and fair dealing. If you can fake that,
you've got it made." -Groucho Marx

Re: Add search path to the cygwin.

[mike corbeil ordinary user account]

David Korn wrote:
> 
> >"Fu, Jack" wrote:
> >>
> >> I tried to add path using $ $PATH=/cygnus/include:$PATH.
> 
> >From: mike corbeil ordinary user account [ mailto:mcorbeil@NetRevolution.com ]
> 
> >      $PATH=/cygnus/include:$PATH
> >      export PATH
> >
> >      or
> >
> >      $PATH=$PATH:/cygnus/include
> >      export PATH
> 
>   PMFBI, but.... surely you mean
> 
>        PATH=/cygnus/include:$PATH
>        export PATH
> 
>  because if you put that first $ sign there, it expands the path, rather
> than treating it as a variable name, so if (for example) your path used to
> be /usr/bin:/bin, then what you've just typed to bash (after expansion) is
> 
>    /usr/bin:/bin=/cygnus/include:/usr/bin:/bin
> 
> which of course doesn't make a lot of sense to bash...


You're abs(right), David Korn.  I've worked with the Korn, Bourne, C,
and Bash shells, much less the buggy C shell, except when doing some
maintenance on scripts I didn't create, and for login shells.  (I wasn't
the sys. admin., either, though it's okay for a login shell - rotten for
programming, comparitively anyway.)

I ooops'd, and what's worse is that I even reviewed what I wrote.  I've
been looking at the screen for too many hours, too many nights and
days.  The eyes go "fuzzy", seeing whitespace instead of $.

Serves as possibly a good little tutorial for the person I was
responding to.  I never programmed or worked in Unix before learning how
to do so and have always had books at hand for reference, for what ever
I was doing, including yours for ksh work.  Perhaps I take that too much
for granted when answering a question, too.

Sorry for the error.

> 
>     hth,
>         DaveK
> --
>  "The secret of life is honesty and fair dealing. If you can fake that,
> you've got it made." -Groucho Marx

RE: Add search path to the cygwin.

[David Korn]

     Hi Mike,

>I ooops'd, and what's worse is that I even reviewed what I wrote.  I've
>been looking at the screen for too many hours, too many nights and
>days.  The eyes go "fuzzy", seeing whitespace instead of $.

  I know just what you mean. Even worse than seeing whitespace for your
prompt is when your eyes start seeing what you *meant* to type instead of
what you actually did. :-O

>Serves as possibly a good little tutorial for the person I was
>responding to.  I never programmed or worked in Unix before learning how
>to do so and have always had books at hand for reference, for what ever
>I was doing, including yours for ksh work.

  I had better point out, for the benefit of the list, that I am no relation
to *that* David Korn. This means that when I try the ego-boosting trick of
searching for my own name on the web I am generally disappointed!

>Sorry for the error.

  No need to apologize. When even an old hand like Alexandre seemed not to
have spotted it (or to have passed over without commenting) I thought I'd
just mention it for the sake of completeness.

   regards,
      DaveK

-- 
 "The secret of life is honesty and fair dealing. If you can fake that,
you've got it made." -Groucho Marx

Re: Add search path to the cygwin.

[mike corbeil ordinary user account]

David Korn wrote:
> 
>      Hi Mike,
> 
> >I ooops'd, and what's worse is that I even reviewed what I wrote.  I've
> >been looking at the screen for too many hours, too many nights and
> >days.  The eyes go "fuzzy", seeing whitespace instead of $.
> 
>   I know just what you mean. Even worse than seeing whitespace for your
> prompt is when your eyes start seeing what you *meant* to type instead of
> what you actually did. :-O

Yep.  Has happened to me before, and maybe that's what happened this
time.

> 
> >Serves as possibly a good little tutorial for the person I was
> >responding to.  I never programmed or worked in Unix before learning how
> >to do so and have always had books at hand for reference, for what ever
> >I was doing, including yours for ksh work.
> 
>   I had better point out, for the benefit of the list, that I am no relation
> to *that* David Korn. This means that when I try the ego-boosting trick of
> searching for my own name on the web I am generally disappointed!

Fast assumption on my part.  I've found around six people, so far, with
the same name as mine, so I should know better.  "Googly" more than just
the eyes.

> 
> >Sorry for the error.
> 
>   No need to apologize. When even an old hand like Alexandre seemed not to
> have spotted it (or to have passed over without commenting) I thought I'd
> just mention it for the sake of completeness.

Well done and it's better that way.  If a person was new to Unix, or
Linux, which ever was being used, and didn't have a decent book to refer
to, then what I had written could certainly be a "byte" of a pain or
nuissance.

I had forgotten the -I command line option to make, though could have
quickly looked it up in the man page (dumb of me to not verify).  I've
read the book on make and the man page, but all of the makes I've ever
had to run had the includes
entirely defined in the Makefile(s), so I forgot about doing it on the
command line.  

Using PATH for this seemed strange and I've no idea if it'd even work
(if it's stated in the book on make or the man page, then I don't
remember this part). I've only used PATH for executables.

Can PATH, or $PATH, actually be used to specify where include files are
located?

mike 

> 
>    regards,
>       DaveK
> 
> --
>  "The secret of life is honesty and fair dealing. If you can fake that,
> you've got it made." -Groucho Marx

Business philosopher as well as good comedian, eh.  I haven't seen any
of his material in years, but only remember a good comic.

RE: Add search path to the cygwin.

[David Korn]

>From: mike corbeil ordinary user account [ mailto:mcorbeil@NetRevolution.com ]
>Sent: 19 October 2000 21:49

>Well done and it's better that way.  If a person was new to Unix, or
>Linux, which ever was being used, and didn't have a decent book to refer
>to, then what I had written could certainly be a "byte" of a pain or
>nuissance.

 Even after several years of experience I still find myself struggling
to remember which shell is which, and whether subshells will inherit my
variables, and which syntax to use for loops, and... and ... and ...
 The power and variety of the Unix shells is a double-edged sword!

>Using PATH for this seemed strange and I've no idea if it'd even work
>(if it's stated in the book on make or the man page, then I don't
>remember this part). I've only used PATH for executables.
>
>Can PATH, or $PATH, actually be used to specify where include files are
>located?

  Not by default, at any rate as far as gcc is concerned. It's an
unlikely thing for any compiler to implement - since there is no
interchangeability between .h files and executables, there's no sense in
only using one environment variable to point to both. OTOH it *could*
be done - you could use a string substitution in the makefile to replace
all the colons between the $PATH components with space, -I, space, and
then prefix that with -I and add it to the compiler CFLAGS. But I've
never seen it done and I can't see any good reason to blur the meaning
of $PATH.

>>  "The secret of life is honesty and fair dealing. If you can fake that,
>> you've got it made." -Groucho Marx
>
>Business philosopher as well as good comedian, eh.  I haven't seen any
>of his material in years, but only remember a good comic.

 And a Discordian saint, too!

           DaveK
-- 
 "The secret of life is honesty and fair dealing. If you can fake that,
you've got it made." -Groucho Marx

Re: Add search path to the cygwin.

[mike corbeil ordinary user account]

David Korn wrote:
> 
> >From: mike corbeil ordinary user account [ mailto:mcorbeil@NetRevolution.com ]
> >Sent: 19 October 2000 21:49
> 
> >Well done and it's better that way.  If a person was new to Unix, or
> >Linux, which ever was being used, and didn't have a decent book to refer
> >to, then what I had written could certainly be a "byte" of a pain or
> >nuissance.
> 
>  Even after several years of experience I still find myself struggling
> to remember which shell is which, and whether subshells will inherit my
> variables, and which syntax to use for loops, and... and ... and ...
>  The power and variety of the Unix shells is a double-edged sword!

Yes and no.  I'd say that it depends on how much a person actually
programs with the Unix shells.  

I've done more than ample to be amply productive at scripting (even if
it's not my favorite thing to do) and found a pesty bug in csh (or one
version thereof), in 98, I never saw reported anywhere, but have never
used csh for development.  I was doing some minor maintenance on a
script written by someone else.  I didn't have a problem with using csh
for a login shell; just for scripting.  

I usually start by reading a good book on a language I'm going to be
working with and the book I had read before writing my first Unix shell
script basically said that Bourne was better for scripting, though said
that this was due to greater portability.  There was no mention of any
bugs in csh, but portability sounded like a good enough reason. 

What I've found to be a bit of a nuissance with bash on Linux, f.e., is
that once or twice what worked before didn't with a newer version, but I
know enough of bash and ksh (pdksh on Linux) to switch back and forth,
and usually write such that only the #! line needs to be modified, to
switch from one to the other.  I also try to make the scripts as
compatible with Bourne, as the purpose of the script permits, for ....,
as you know.

I now mostly use Perl.  After seeing things that once worked in bash
break in a newer version, and then being unable to do something in ksh
(pdksh), I think for a similar reason (i.e., something broken), Perl
quickly became a mainstay for scripting, and will remain that way.  I'll
only bother with bash or pdksh for very simple scripts, or for something
Perl is not as good for (?).

So, what ever problems there may have been in the past with Unix shell
languages, these don't exist anymore, not for moi anyway, and I like
things to be this way.  Besides, I prefer Perl over the others, except
for purposes the others are easier to use for.

There are many ways to do many things and I'm not one to sacrifice
productivity if it's unnecessary to do so, but without sacrificing
quality (when important or of practical value).  There are various
considerations to arrive at a balance of productivity and quality, at
least for those who must deal with the issue of productivity (maybe some
don't).

Perl is a winner for scripting.  Even if it is cryptic in some ways,
this is offset by writing readable code and the various qualities of the
language.  It's definitely adequate for many tasks, but not a panacea. 
However, no programming language or tool or OS is a panacea, either.  

This is one reason I asked for input re. Eiffel, because scripting is
not my mainstay.  I'm not a sys. admin, but am gaining more knowledge in
this respect through the administration of my Linux system and being
curious by nature.  I like to explore.  Variety is also good and
healthy, in more ways than one.

There's a fair amount to learn and much more available.  I'm making
Linux, Perl, and Eiffel a personal project.  Eiffel should or will be
easier to master than Perl, but to be productive with Perl doesn't
require knowing all of it in all of its TIMTOWTDI nature.  

These should make a very good skill set, though I say this because most
jobs I've worked required a broad range of skills.  I didn't do just C
programming for 5, 6, ... years, and nothing else.  I don't know what
employers or potential prospective clients with interesting projects
would think seeing the variety on my resume, but some have seemed to be
interested.  I only know what I had to do and did; had to, in the sense
of either do or look for another job, but then "the grass often looks
greener nextdoor" => ..., sometimes anyway.


> 
> >Using PATH for this seemed strange and I've no idea if it'd even work
> >(if it's stated in the book on make or the man page, then I don't
> >remember this part). I've only used PATH for executables.
> >
> >Can PATH, or $PATH, actually be used to specify where include files are
> >located?
> 
>   Not by default, at any rate as far as gcc is concerned.


Didn't think it would be, for I've never seen or even heard of $PATH
being used for this purpose.


 It's an
> unlikely thing for any compiler to implement - since there is no
> interchangeability between .h files and executables, there's no sense in
> only using one environment variable to point to both.


You're right, there isn't any sense.  $PATH is for executables, and
that's how it should remain.

However, I think (not that anyone would want to do or use this) that if
you define a path to a text file in $PATH and make the file +x, then
`which` may find the file.  I seem to remember having tested this once,
while investigating ways of easily finding non-exec files, and think it
worked, but didn't use this approach and definitely wouldn't use it for
make to find includes.  I'm so sure I did this and that it worked that I
won't test it now.


 OTOH it *could*
> be done - you could use a string substitution in the makefile to replace
> all the colons between the $PATH components with space, -I, space, and
> then prefix that with -I and add it to the compiler CFLAGS. But I've
> never seen it done and I can't see any good reason to blur the meaning
> of $PATH.


I'd never bother with that.  I have no problem with the way make works,
now.

$PATH is better off being kept with its present purpose and this can be
perceived as abiding by the KISS prin.


> 
> >>  "The secret of life is honesty and fair dealing. If you can fake that,
> >> you've got it made." -Groucho Marx
> >
> >Business philosopher as well as good comedian, eh.  I haven't seen any
> >of his material in years, but only remember a good comic.
> 
>  And a Discordian saint, too!


I think that he wasn't the first.

mike


> 
>            DaveK
> --
>  "The secret of life is honesty and fair dealing. If you can fake that,
> you've got it made." -Groucho Marx