Re: Add search path to the cygwin.

[mike corbeil ordinary user account <mcorbeil at NetRevolution dot com>]

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