[ On , September 30, 2000 at 17:58:40 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: setting and using progname.
>
> woods@weird.com (Greg A. Woods) writes:
> > Is this a good/necessary idea?  I'd rather be able to reset the value.
> 
> I'd rather you not.  This is supposed to be the name of the program as
> invoked by the user.  That doesn't change.

Looking at just the basename of argv[0] is already losing lots of
information, never mind that argv[0] may not be what the user specified
anyway -- it's only that way by convention of most shells.

Until someone calls setproctitle()....   :-)

Besides this is a user-space thing -- if you don't make it easy to
change after the fact people will just open up the black box and clobber
__progname or whatever anyway.

> uh, neither modify argv[0].  (or at least, the code that i provided
> didn't, and I don't think basename should...  if it does, it's
> implemented ... interestingly.)

Sorry -- I was confusing myself.

Both dirname() and basename() can modify the array they're passed a
pointer to since they both strip trailing slashes from it.  Dirname() of
course also always clobbers the last slash (after stripping trailing
slashes) in order to terminate the directory pathname without copying
it.

> Right, so then the problem becomes "every program and its cousin
> define a function do print an error message an exit, each slightly
> different, half slightly wrong."

I know...   :-(

some programs still do their own thing anyway -- it's only through
meticulous audits and cleanups that such consistency is maintained.

> It's not particularly hard to create such a portability library, and
> it's actually not too large.  it really depends on what you're trying
> to port.

Yup.  I'm not truly holding my breath on this goose and gander thing.  :-)

> the things that annoy me are:
> 
> * places where you've got programs including other programs source
> files via path tricks.  Great, one less copy in the source tree, but
> that can be a bit of maintenance hair if you're porting things to
> other systems...

Indeed.

If the shared code is really that useful then shouldn't it be in a
library?  :-)

> * the huge amount of deviation that has to be worked around in N
> places, e.g. inclusion of sys/cdefs.h at the top of every file, use of
> __P in user programs, use of non-standard header files, etc.  You can
> for the most part work around these by defining a "compatiblity"
> header, then going through and #if'ing out all of the non-standard
> #includes... but some are more annoying (e.g. the __COPYRIGHT etc.,
> stuff from cdefs.h -- you can't sanely include a general compat header
> at the top of the src file so then you need two...), and even though
> each may be individually easy, you tend to have to touch N lines of
> code in each file.  yuck.

Hmmm....  I find myself keeping a "portable" likeness of <sys/cdefs.h>
around and using it even in new programs.  I find the idioms it
introduces are useful for making things more portable.  I don't use the
macros that are now in sys/cdefs_*.h though and I agree they can be
rather annoying.

Now if the pkgsrc "zoularis" stuff already had the portability headers
and library as a package instead of requiring a full source tree....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>