RE: Add search path to the cygwin.

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.

[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

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:
> 
>      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]

     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.

[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.

[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).

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