On Mon, 18 Jun 2001 [EMAIL PROTECTED] wrote:
>>Something is either portable or it isn't. When trying to be
>>portable, one should choose programs ran from shellscripts with
>>care so that they run on as many OS's out there as possible.
>
>>If one wants to use snazzy modern features, that is ok, but it
>>should be done in a way that falls back to portable methods.
>
>It turns out that if you think about your problem, you often find that
>the new features are completely unneeded. .... and if so, why
>adding non-portable demands to your software?
Yep, I agree with that also. It depends though on the goals of
such software. There are applications I have written that were
somewhat of a research thing for myself, to "scratch a personal
itch" and had no need of being portable. It isn't uncommon in
the open source world for this to be the case when writing new
software. Many times one doesn't even plan on making their
sofware available widely, and it only becomes an afterthought.
I've got a fair number of bash2 scripts here. If I release them
to people, they are portable as far as I'm concerned - bash2 is
it's own language, so it will work on any system where bash2 is
installed. I would not modify these scripts to be bourne shell
compliant as it would severely complicate the code and make
maintenance a nightmare. I'd rather keep the scripts to myself
than release them and have someone be upset about nonportability
- just as an example. So there are circumstances where it is
acceptable IMHO to be non-portable as well. It really depends on
the problem domain - but one should try to be portable if
possible as long as it doesn't overcomplicate things beyond the
problem domain, project goals, etc.
>The main problem is that many people who are new to UNIX and have no
>background knowledge on how things should be done create nonportable
>software by yust peeking into the features of Linux.
That is true, yes.
>An important fact is that the first solution in many times is not
>the best solution.
>
>This is why I higly demand people to read the documentation on:
>
> http://www.opengroup.org/onlinepubs/7908799/
>
>in favor of the Linux manuals. There are two reasons:
s/demand/suggest/ would seem appropriate, yes.
>1) many Linux manuals are not reflecting the programs currectly
> because FSF things that you don't need manuals :-(
Free software documentation is often not in sync with reality, or
completely accurate, yes. More documentation is always useful.
>2) Linux includes a lot of programs with (completely
> unneded) non standard options and features.
>
>It always helps to first read the Official man page from Opengroup
>and then compare the content with the OS you are using.
That's not bad advice at all. Many people however are Linux
programmers and are not concerned with massive portability. If
portability issues are a boon to someone's set goals, they are
likely to do things nonportably. Also, many people simply are
not aware of some portability issues. More frequently I find
portability issues WRT endianness, or assumptions of word size or
alignment. Unless someone has used a system where these issues
are a reality though it is sensible to expect they will likely
write nonportable software. 64 bit computing is not within easy
and convenient reach of a good majority of Linux developers out
there for example. Everyone has access to some sort of 32bit x86
box though so often assumptions are made that work there.
Similarly not everyone has access to Solaris, HPUX, etc.. but
they likely have access to Linux much more readily so it is
understandable that they can also make bad assumptions there
also.
----------------------------------------------------------------------
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc. Ontario, Canada, P6C 5B3
http://www.redhat.com Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS: ftp://people.redhat.com/mharris/testing
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
