Prev: Parsing GC Log File
Next: Is it possible to automatically download new software when it's released?
From: bsh on 16 Nov 2009 16:31
Dominic Fandrey <kamik...(a)bsdforen.de> wrote:
> Shell scripting often is a purpose of its own. It's really more of an
> art form than real programming, yet ridiculously real programs still are
> the result. Consider me a wannabe artist who is bad at handling critics.
(How is it that your English is so fluent and idiomatic?)
Hmmm, interesting. Despite allusions to the code by previous
respondents, I had to find it with a Web search to review it.
It haven't been able to run it (no shell prompt in front on me
these days) but have been personally interested in doing such
a thing recently, as a author of an (unreleased) k/sh IDE.
I see that Christopher A. Jones'es book "UNIX Shell Objects"
has now been introduced, and I need to add nothing about it
here, except that it is pdksh, not ksh of any version, in
which the scripts are written in -- and it does make a bit of
difference, insofar as there are semantic nuances of pdksh
which are significant.
I would be interested in what you have to saw about your
"bsda_obj.sh" in regards to the below list of prior attempts
to add an OOP paradigm to k/sh. It is a (mostly) comprehensive
"<Unix Shell Objects.sh> -- OOP extension to ksh(1) and applications
from BOOK: Christopher A. Jones. "UNIX Shell Objects: Developing
Multilayered, Distributed, Object-Oriented Applications Using the Korn
Shell". ISBN 0-7465-7004-8.
"shoop.sh" -- classless object orientation (introspection,
finalization, serialization, multiple inheritance) to plain sh(1)
same as above??
TRACT: Jeffrey S. Haemer. "A new object-oriented programming
Proceedings of the USENIX Summer 1994 Technical Conference on USENIX.
Summer 1994. Technical Conference, p.1-1, 1994-06-06P06-10, Boston.
^ QT: Introduces a tiny, object-oriented programming system written
entirely in POSIX-conforming shell scripts.
"Idee Sparse Per Shell Object-Oriented"
"ksh93 OOP using discipline functions"
And here are two of my past contributions to C.U.S.
that are pertainent:
"OO methodology implemented through file system":
"Organization of shell code function library":
> I am working on a rather complex application and the cleaner
> data structures safe enough computation time to outweigh the
> considerable overhead caused by the framework.
Because your application is non-trivial, I would myself think to
implement it with the robust, if under-documented, O-O capability
now built into ksh93t and later.
Perhaps you think that to write in sh(1) has the advantage of
portability? It used to be so, but now that ksh93(1) is open-
source and freely downloadable, and the fact the Bourne shell
development lineage has become so "forked" with POSIX
compliance and back-implemented, host-specific features,
its now impossible to reliably assume a given feature set
used in sophisticated scripting.
Good luck. Please let C.U.S. know of revisions and comments --
I can say that I understand the general arguments of some
previous responents, but I hope that this will not dissuade
you from posting any such followups.
From: Janis Papanagnou on 16 Nov 2009 19:35
Dominic Fandrey wrote:
> Janis Papanagnou wrote:
>> Dominic Fandrey wrote:
>>> Inheritance can be VERY useful, but often is not required at all.
>> Well, YMMV, but OO just *starts* with inheritance; one of the few basic
>> OO features is polymorphism, and inheritance is a precondition for that.
> No it isn't. It only is a precondition if there is type safety.
You're again wrong with your claim.
Thanks for your time and goodbye.
From: Janis Papanagnou on 16 Nov 2009 19:42
Thanks for the links.
> "ksh93 OOP using discipline functions"
The latter link seems either broken or wrong.
Any more information about it?
From: Dominic Fandrey on 17 Nov 2009 06:49
> Dominic Fandrey <kamik...(a)bsdforen.de> wrote:
>> Shell scripting often is a purpose of its own. It's really more of an
>> art form than real programming, yet ridiculously real programs still are
>> the result. Consider me a wannabe artist who is bad at handling critics.
> (How is it that your English is so fluent and idiomatic?)
I have no idea what idiomatic means. The explanations I found
do not really enlighten me. I glimpse that it might mean that
the meaning of my words is clouded. If so I apologize, I am
not a native speaker as you no doubt have recognized.
In deed, apart from 20 days in Great Britain more than five
years ago, I have not been to a country where English or one of
its derivatives is the native tongue.
> Hmmm, interesting. Despite allusions to the code by previous
> respondents, I had to find it with a Web search to review it.
I really should post an updated version somewhere, one that comes
with inheritance and serialization. After some fixing up of the
documentation I will.
> I would be interested in what you have to saw about your
> "bsda_obj.sh" in regards to the below list of prior attempts
> to add an OOP paradigm to k/sh. It is a (mostly) comprehensive
Pursuing this will take me some time. Maybe as much as two or
three weeks. Your list and questions are very appreciated.
Be assured, I will not forget to respond when I am ready.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing on usenet and in e-mail?
From: Seebs on 17 Nov 2009 10:49
On 2009-11-17, Dominic Fandrey <kamikaze(a)bsdforen.de> wrote:
> I have no idea what idiomatic means. The explanations I found
> do not really enlighten me.
"Idioms" are patterns of usage which aren't directly derived from the
grammar or semantics of individual words. "Idiomatic" writing in any
language (even a computer language) is language which conforms to the
> I glimpse that it might mean that
> the meaning of my words is clouded. If so I apologize, I am
> not a native speaker as you no doubt have recognized.
No, it actually means the opposite.
Note that "idiomatic" applies to shell, as well. For instance, if I'm
modifying IFS, I pretty much always write:
(do something using new IFS)
Since I write it the same way every time, anyone reading my scripts knows
what I'm doing and how.
For instance, consider the occasional portability problem you might encounter
if [ "$x" = none ]; then
There have been variants of test where some values of $x could cause the
test parser to get confused by the expresison. Furthermore, the lack
of quotes around "none", while irelevant, can make it harder to see the
parallel. Many people use the convention of adding an initial value.
Thus, you might see:
if [ X"$x" = X"none" ]; then
This makes it reasonably easy for the reader to see the difference.
Now, imagine that you saw this:
if [ $(echo x)"$x" = $(echo X | tr A-Z a-z)'n''o''n''e' ]; then
A bit of examination reveals that they're equivalent, I think -- but it's
a lot harder to tell. The first usage is considered "idiomatic" -- it is
the solution to that particular problem that users are most likely to be
There are some cases where an idiom is unclear.
x=$(eval echo foo_$y)
The former is a pretty widely-used idiom, but the latter is actually noticably
superior in terms of how it handles special characters, etcetera.
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!