object oriented shell scripts
Dominic Fandrey
It doesn't provide type safety or inheritance or access control,
but it has classes, objects and some other nice features like
automatic creation of getters and setters or return by reference.
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.
If you're interested in using it or porting it to the /bin/sh of
a different operating system (currently runs on FreeBSD), feel
free to contact me.
The following is some working demo code that illustrates how
it is used. It outputs the fibonacci numbers 8 and 7:
21
13
#!/bin/sh
#
# A small demo of "bsda_obj.sh", which demonstrates
# return by reference. Note that this is even works
# safely when the variables within a method have the
# same names as the variables in the caller context
# (such as is the case for recursive methods).
#
# These features are really just useful byproducts
# of my desire to write object oriented shell
# scripts.
#
# Import framework.
. bsda_obj.sh
# Declare the class.
bsda_obj:createClass Demo \
w:value \
This is a comment \
x:fibonacciRecursive \
"This is a comment, too. <== my prefered style" \
#
# Implementation of the fibonacciRecursive method for the
# Demo class.
#
# Yes I know that this is the least efficient way of
# doing this, but it demonstrates what I want it to.
#
# @param 1
# The variable to store the fibonacci value in.
# @param 2
# The index of the fibonacci value to return.
#
Demo.fibonacciRecursive() {
# Terminate recursion.
if [ $2 -le 2 ]; then
$caller.setvar "$1" 1
return 0
fi
local f1 f2
$this.fibonacciRecursive f1 $(($2 - 1))
$this.fibonacciRecursive f2 $(($2 - 2))
$caller.setvar "$1" $(($f1 + $f2))
}
# Create instance.
Demo demo
# Call the fibonacci method from instance and ...
# ... store the result in the value variable.
$demo.fibonacciRecursive value 8
# ... print the result.
$demo.fibonacciRecursive '' 8
# Set an attribute.
$demo.setValue $(($value - $($demo.fibonacciRecursive '' 6)))
# Get an attribute and ...
# ... store the result in the value variable.
$demo.getValue value
# ... print the attribute.
$demo.getValue
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Ed Morton
> I have written a framework for object oriented shell scripting.
> It doesn't provide type safety or inheritance or access control,
> but it has classes, objects and some other nice features like
> automatic creation of getters and setters or return by reference.
Then it's object-based, not object-oriented.
> 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.
Maybe you're trying to do too much in shell if the design paradigm
makes such a big difference!
Ed.
Dominic Fandrey
> On Nov 10, 11:10 am, Dominic Fandrey <kami...@bsdforen.de> wrote:
>> 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.
>
> Maybe you're trying to do too much in shell if the design paradigm
> makes such a big difference!
No dependencies outside the base system. The one rule I must not
break.
Regards
Ed Morton
> >> 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.
>
> > Maybe you're trying to do too much in shell if the design paradigm
> > makes such a big difference!
>
> No dependencies outside the base system. The one rule I must not
> break.
Doesn't creating an object-based middleware framework that has to be
implemented on your base contradict that requirement? I mean, what's
the difference between doing that and just installing Java or similar?
Either way you're introducing something that's potentially beyond the
realm of expertise of anyone who knows the "base" and has to work on
your code in future, but at least they might know Java already, and
there's probably already a version of Java that'll run on whatever
your next "base" is other than freeBSD if it's portability you care
about.
Ed.
Janis Papanagnou
> I have written a framework for object oriented shell scripting.
> It doesn't provide type safety or inheritance or access control,
> but it has classes, objects and some other nice features like
> automatic creation of getters and setters or return by reference.
I think the getter and setter is the most unimportant feature in an
object based approach. And all the Real OO Features are missing?
BTW, you may want to have a look into a newer ksh93 and its typeset
builtin command with its options...
[Option -n]
Declares vname to be a reference to the variable whose name
is defined by the value of variable vname. This is usually
used to reference a variable inside a function whose name
has been passed as an argument.
[Option -T]
With the -T option of typeset, the type name, specified as
an option argument to -T, is set with a compound variable
assignment that defines the type. Function definitions can
appear inside the compound variable assignment and these
become discipline functions for this type and can be invoked
or redefined by each instance of the type. The function name
create is treated specially. It is invoked for each instance
of the type that is created but is not inherited and cannot
be redefined for each instance.
And see the manual about the very interesting discipline functions.
...in case you want to use one of the newer standard shells out there.
(Don't know of any more detailled documentation or tutorial, though.)
Janis
Dominic Fandrey
> On Nov 10, 2:25 pm, Dominic Fandrey <kamik...@bsdforen.de> wrote:
>> Ed Morton wrote:
>>> On Nov 10, 11:10 am, Dominic Fandrey <kamik...@bsdforen.de> wrote:
>>>> 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.
>>> Maybe you're trying to do too much in shell if the design paradigm
>>> makes such a big difference!
>> No dependencies outside the base system. The one rule I must not
>> break.
>
> Doesn't creating an object-based middleware framework that has to be
> implemented on your base contradict that requirement? I mean, what's
> the difference between doing that and just installing Java or similar?
Do you really think using a 758 lines (19kB) shell script framework
is an act comparable to installing a JDK?
OpenJDK uses 124MB on my hard disk, that's more than 6500 times
the space required by my little framework.
> ... but at least they might know Java already, and
> there's probably already a version of Java that'll run on whatever
> your next "base" is other than freeBSD if it's portability you care
> about.
Sure I could write my scripts in Java. However no one would use them
if I did. Not even me.
Ah, I enjoy these pointless discussions.
Ed Morton
> Ed Morton wrote:
> > On Nov 10, 2:25 pm, Dominic Fandrey <kamik...@bsdforen.de> wrote:
> >> Ed Morton wrote:
> >>> On Nov 10, 11:10 am, Dominic Fandrey <kamik...@bsdforen.de> wrote:
> >>>> 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.
> >>> Maybe you're trying to do too much in shell if the design paradigm
> >>> makes such a big difference!
> >> No dependencies outside the base system. The one rule I must not
> >> break.
>
> > Doesn't creating an object-based middleware framework that has to be
> > implemented on your base contradict that requirement? I mean, what's
> > the difference between doing that and just installing Java or similar?
> > ...
>
> Do you really think using a 758 lines (19kB) shell script framework
> is an act comparable to installing a JDK?
No, I think you'd be significantly better off with the JDK.
> OpenJDK uses 124MB on my hard disk, that's more than 6500 times
> the space required by my little framework.
>
> > ... but at least they might know Java already, and
> > there's probably already a version of Java that'll run on whatever
> > your next "base" is other than freeBSD if it's portability you care
> > about.
>
> Sure I could write my scripts in Java. However no one would use them
> if I did. Not even me.
>
> Ah, I enjoy these pointless discussions.
Well, good luck with your enterprise anyway.
Regards,
>
> --
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?- Hide quoted text -
>
> - Show quoted text -
Stachu 'Dozzie' K.
> Ed Morton wrote:
>> On Nov 10, 2:25 pm, Dominic Fandrey <kamik...@bsdforen.de> wrote:
>>> Ed Morton wrote:
>>>> On Nov 10, 11:10 am, Dominic Fandrey <kamik...@bsdforen.de> wrote:
>>>>> 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.
>>>> Maybe you're trying to do too much in shell if the design paradigm
>>>> makes such a big difference!
>>> No dependencies outside the base system. The one rule I must not
>>> break.
>>
>> Doesn't creating an object-based middleware framework that has to be
>> implemented on your base contradict that requirement? I mean, what's
>> the difference between doing that and just installing Java or similar?
>> ...
>
> Do you really think using a 758 lines (19kB) shell script framework
> is an act comparable to installing a JDK?
>
> OpenJDK uses 124MB on my hard disk, that's more than 6500 times
> the space required by my little framework.
But digging through your 20kB framework plus the rest of your code would
be much harder than reading Python or Ruby[*] scripts of the same size
(minus 20kB framework). And you gain the same execution speed as shell,
compared to Java. I think Ed just unnecessarily mentioned Java.
[*] I would suggest Perl, but you need to be really good Perl programmer
already to write readable and maintainable code in it.
--
Stanislaw Klekot
Dominic Fandrey
I am here to discuss shell scripting. I created something crazy yet still
useful, because I wanted to, because I can and because I need it.
Why do you keep insisting that I shouldn't have done it? Do you grudge
me the joy of achieving what few have achieved before me?
You can all bitch about Java, Perl and Python somewhere else, e.g. in a
Java, Perl or Python group.
The purpose of this was to share what I am doing with whomever is
interested. I am not interested in any of your opinions about why it
shouldn't have been done.
The proper way of showing me your disinterest is leaving me alone.
Dominic Fandrey
> Dominic Fandrey wrote:
>> I have written a framework for object oriented shell scripting.
>> It doesn't provide type safety or inheritance or access control,
>> but it has classes, objects and some other nice features like
>> automatic creation of getters and setters or return by reference.
>
> I think the getter and setter is the most unimportant feature in an
> object based approach. And all the Real OO Features are missing?
To me inheritance and access control are only useful tools, not
necessary for the concept to work. Especially access control is
not required at all, it can completely be substituted with discipline.
Inheritance can be VERY useful, but often is not required at all.
Though it's not supported by my little framework, you can at least
reuse methods from other classes simply by creating an alias or
directly calling them as a static function. In that case, they
won't get their own stack layer, though and everything they return
by reference will not be returned to you, but to whomever called
your method.
> BTW, you may want to have a look into a newer ksh93 and its typeset
> builtin command with its options...
Those really sound like interesting options. ksh is not part of
the FreeBSD base system, can you name a system where it is? Do you
think it's possible to port Bourne Shell code or even write code
that works on both shells?
Or do those features make my framework entirely obsolete for
this shell?
Ed Morton
For my part, I was just trying to understand why you did it to get an
idea of when it'd be useful. You're taking the questions and alternative
suggestions kinda personally.
> You can all bitch about Java, Perl and Python somewhere else, e.g. in a
> Java, Perl or Python group.
And what newsgroup would it be where we respond to a comp.unix.shell
post about someone creating an object-oriented language in shell and
simply ask why they didn't just use an existing object-oriented language
if they wanted to do OOP?
> The purpose of this was to share what I am doing with whomever is
> interested. I am not interested in any of your opinions about why it
> shouldn't have been done.
Oh, so you get to post whatever you like and no-one can question you
about it or suggest alternatives for everyone else who's reading it. I see.
> The proper way of showing me your disinterest is leaving me alone.
Those who were disinterested did leave you alone. I was interested but
had a couple of questions. I'm sure you're very proud of your framework
and put a lot of thought and effort into it, but remember it's just your
code, not your kid.
Ed.
Dominic Fandrey
It didn't get across to me like that. So I'm sorry about misunderstanding
you. My frustration comes from already having answered that question and
still being asked about it.
Still I can produce a more elaborated answer:
I am using the framework in a binary package management command line tool
for FreeBSD. The community rejects any command line package management
tool that depends on other packages. Native binaries (from C code) would
be accepted, but only if they were part of the FreeBSD project, not as a
third party application.
So whatever language apart from awk or sh I use, it would result in the
tool loosing all its users.
>> You can all bitch about Java, Perl and Python somewhere else, e.g. in a
>> Java, Perl or Python group.
>
> And what newsgroup would it be where we respond to a comp.unix.shell
> post about someone creating an object-oriented language in shell and
> simply ask why they didn't just use an existing object-oriented language
> if they wanted to do OOP?
Probably no where. I will state more clearly what kind of answers
I'm interested in and leave everything alone in the future.
>> The purpose of this was to share what I am doing with whomever is
>> interested. I am not interested in any of your opinions about why it
>> shouldn't have been done.
>
> Oh, so you get to post whatever you like and no-one can question you
> about it or suggest alternatives for everyone else who's reading it. I see.
It sounds kinda bad this way, but I suppose that's the core of the issue. ;)
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.
>> The proper way of showing me your disinterest is leaving me alone.
>
> Those who were disinterested did leave you alone. I was interested but
> had a couple of questions. I'm sure you're very proud of your framework
> and put a lot of thought and effort into it, but remember it's just your
> code, not your kid.
Noted.
Maxwell Lol
> And what newsgroup would it be where we respond to a comp.unix.shell
> post about someone creating an object-oriented language in shell and
> simply ask why they didn't just use an existing object-oriented
> language if they wanted to do OOP?
I think this is a fine newsgroup for the discussion.
Of course there's a big difference between inventing a new OO language
and inventing an object oriented language for interactive scripting,
especially if it can be mixed with POSIX shell commands.
A OO shell might be useful on the command line. If, for example, one
could pass objects between shell commands instead of text, and where
one can mix objects with text. Think of somelike like an object
oriented awk (which might be built into the shell):
grep -v 'DEBUG' <file | encapsulate oclass |\
ooawk '{ .func && .ip->print, .date->print}' |\
oosort .date| decapsulate | lpr
Where oclass is an object class definition that has
function func
date is a timestamp. perhaps from a log file
ip is an IP address field
Encapsulate(1) converts from text into OO format. Decapsulate does the
opposite. Perhaps these could be symbols instead of functions.
We just had a case where people wanted to sort by dotted IP addresses.
It should have it's specialized print function. And oosort would know
how to sort an IP address, a time stamp, etc.
I certainly don't want to use a language like Java for one- or
two-line shell scripts. Buf if I could mix POSIX shell with OO stuff,
that would be interesting.
AIR, others have tried OO shells. I admit I never looked into these
in detail, but google pointed me to:.
http://geophile.com/osh/
http://mediakey.dk/~cc/bash-shell-object-oriented/
You know, I often have to use perl or shell to parse log files. If
would be nice to have an object class that one can take any log file,
and convert a text file into a consistent data structure, thst a small
set of tools could operate one.
Stachu 'Dozzie' K.
[...]
> I am here to discuss shell scripting. I created something crazy yet still
> useful, because I wanted to, because I can and because I need it.
>
> Why do you keep insisting that I shouldn't have done it? Do you grudge
> me the joy of achieving what few have achieved before me?
OK, great job, good work, the king rules and so on. But what is it for?
You know, I tend to use the appropriate tool for the job. I drop the
shell if the job requires more sophisticated text processing. I drop
scripting languages when I need fast computation or something from deep
system (SUID binaries, PAM libraries or something).
If your system needs OOP, then just drop the shell and go get some
language supporting that paradigm. That's simply clearer and easier
approach (both for you and people using your work).
--
Stanislaw Klekot
Janis Papanagnou
> Janis Papanagnou wrote:
>> Dominic Fandrey wrote:
>>> I have written a framework for object oriented shell scripting.
>>> It doesn't provide type safety or inheritance or access control,
>>> but it has classes, objects and some other nice features like
>>> automatic creation of getters and setters or return by reference.
>> I think the getter and setter is the most unimportant feature in an
>> object based approach. And all the Real OO Features are missing?
>
> To me inheritance and access control are only useful tools, not
> necessary for the concept to work. Especially access control is
> not required at all, it can completely be substituted with discipline.
(Even all Object Oriented or Object Based programming concepts can be
substituted with discipline in programming; not a convincing argument,
BTW.)
> 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.
(Ed suggested to use another term to be clear about your framework's
range and intention.)
I sort of agree with you statement about access control to a certain
degree.
> Though it's not supported by my little framework, you can at least
> reuse methods from other classes simply by creating an alias or
> directly calling them as a static function. In that case, they
> won't get their own stack layer, though and everything they return
> by reference will not be returned to you, but to whomever called
> your method.
>
>> BTW, you may want to have a look into a newer ksh93 and its typeset
>> builtin command with its options...
>
> Those really sound like interesting options. ksh is not part of
> the FreeBSD base system, can you name a system where it is?
The situation is not that simple - well, maybe it is. Ksh is part of
most (every?) commercial Unix that was shipped the last 20+ years,
and there's a PD ksh on Linux systems. Bad news is that those are
mostly ksh88 based versions, and the above quoted features are from
newer ksh93. Good news is that ksh93 is available (source and binary
for many platforms) from kornshell.com.
> Do you
> think it's possible to port Bourne Shell code or even write code
> that works on both shells?
Yes and no, depending on how your question is interpreted. Ksh is
(as far as possible) an extension of Bourne shell (as is bash, for
example), so quite all bourne shell programs should also work on ksh
(or bash). Ksh also conforms to the POSIX standard. But, of course,
backwards is not guaranteed; you cannot run a ksh program using e.g.
the discipline function feature on a Bourne shell; Bourne shell is a
more primitive predecessor.
> Or do those features make my framework entirely obsolete for
> this shell?
Well, I suppose so, but from the interface usage example you posted I
cannot tell for sure, to be honest.
One additional question resp. remark to your posted code; you are using
the 'local' keyword, could it be that the freeBSD sh is actually a bash?
You might get portability problems if you run your programs on a real sh
in this case. Or is 'local' a keyword introduced and supported by your
framework?
Janis
stan
<snip>
> The proper way of showing me your disinterest is leaving me alone.
I see you're new to usenet. Welcome.
Charles Polisher
> Dominic Fandrey wrote:
>> Janis Papanagnou wrote:
>>> Dominic Fandrey wrote:
>>>> I have written a framework for object oriented shell scripting.
>>>> It doesn't provide type safety or inheritance or access control,
>>>> but it has classes, objects and some other nice features like
>>>> automatic creation of getters and setters or return by reference.
>>> I think the getter and setter is the most unimportant feature in an
>>> object based approach. And all the Real OO Features are missing?
Cf. "UNIX Shell Objects", Christopher A. Jones, ISBN 0-7465-7004-8
subtitled "Developing Multilayered, Distributed, Object-Oriented
Applications Using the Korn Shell".
Best of luck,
--
Charles Polisher
Janis Papanagnou
And what exactly will we find in this book? (Descriptions of the new
typeset -T features? Emulating OO by disciplined programming? A more
elaborated framework to support OO better than in an object based
approach?) Being a bit more verbose would help. Thanks.
>
> Best of luck,
Charles Polisher
> Charles Polisher wrote:
>> Cf. "UNIX Shell Objects", Christopher A. Jones, ISBN 0-7465-7004-8
>> subtitled "Developing Multilayered, Distributed, Object-Oriented
>> Applications Using the Korn Shell".
>
> And what exactly will we find in this book? (Descriptions of the new
> typeset -T features? Emulating OO by disciplined programming? A more
> elaborated framework to support OO better than in an object based
> approach?) Being a bit more verbose would help. Thanks.
Sure... this will be my first ever book report, but here goes!
(BTW, he touches not at all on typeset. Maybe that's because it
was published in 1998. I'm not sure what you meant by your
other questions, but I'll be happy to elaborate if my little
review fails to satisfy.)
This paperback book is 425pp, includes a CD-ROM with all the
code from the book. The book is aimed at UNIX SysAdmins
who have beginning to intermediate skills in shell scripting.
The book begins with a background chapter on OOP which
covers class basics using a Hello, World! type of
program written as a Korn shell class. He covers
encapsulation, inheritance, and polymorphism with more
simple examples to illustrate his points. As he does
throughout the book, the author provides fully worked
example code.
The next chapter is a review of shell scripting in
general. He makes some assertions about the relative
merits of different approaches to shell scripting, and
then presents measurements to support his recommendations.
Chapter 3 goes into detail about writing shell classes
and touches on interfaces, constructors, accessors,
data members, methods and destructors.
Next, the author tackles several real-world applications
of shell OOP, including classes for disks, users,
machine accounts, a container (list) class, some
subclassing, and a server class. He presents a class
factory.
Following is a chapter on object communication and
event handling.
The next 2 chapters jump into a mix of Java and
shell scripting, which I found a bit out of place.
Chapter 8 covers distributed objects, and defines
a distributed object protocol for Korn shell.
Chapter 12 covers application of his constructs to
CGI programming.
Overall, there is much good material in this book.
I found it an enjoyable read and worth the cover
price of US$40. Amazon lists several used copies for
under US$6.
I sense that you would like an analysis of how well
constructed his implementation is, but that would
be more than I feel qualified to undertake.
--
Charles Polisher
Janis Papanagnou
Thanks for providing that information.
My questions - indeed I have some - go not as far as you fear[*]
(I think), they're rather very basic and I could not derive it
from what you wrote.
What exactly is that "Korn shell class"; a part of a framework
the author provides to build OO sources on top, or just a
methodology how to use standard shell constructs to achieve OO?
How does such a "Korn shell class" look like. I'd especially be
interested whether that framework(?) supports polymorphism (it
seems just to be mentioned in the "background chapter", but it's
probably readily supported?) and ideally how that would look like
in a small example. Thanks.
Janis
[*] I'd indeed be interested in the implementation (WRT used data
structures and impact on performance), but to get an impression
of the user interface is interesting as well, probably also for
the OP.
Charles Polisher
> Charles Polisher wrote:
>> On 2009-11-13, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>> Charles Polisher wrote:
>>>> Cf. "UNIX Shell Objects", Christopher A. Jones, ISBN 0-7465-7004-8
>>>> subtitled "Developing Multilayered, Distributed, Object-Oriented
>>>> Applications Using the Korn Shell".
>>> And what exactly will we find in this book? (Descriptions of the new
>>> typeset -T features? Emulating OO by disciplined programming? A more
>>> elaborated framework to support OO better than in an object based
>>> approach?) Being a bit more verbose would help. Thanks.
<snip>
> Thanks for providing that information.
>
> My questions - indeed I have some - go not as far as you fear[*]
> (I think), they're rather very basic and I could not derive it
> from what you wrote.
>
> What exactly is that "Korn shell class"; a part of a framework
> the author provides to build OO sources on top, or just a
> methodology how to use standard shell constructs to achieve OO?
> How does such a "Korn shell class" look like. I'd especially be
> interested whether that framework(?) supports polymorphism (it
> seems just to be mentioned in the "background chapter", but it's
> probably readily supported?) and ideally how that would look like
> in a small example. Thanks.
>
> Janis
>
> [*] I'd indeed be interested in the implementation (WRT used data
> structures and impact on performance), but to get an impression
> of the user interface is interesting as well, probably also for
> the OP.
A very simple example from the book,
##---- A person class
## Constructor
_person() {
_strName=$1
_nAge=$2
}
## Accessors
_getName() {
echo $_strName
}
_setName() {
_strName=$1
}
_getAge() {
echo $_nAge
}
_setAge() {
_nAge=$1
}
##---- End of person class
$> shcc person.cls # run the compiler (written in Korn shell)
$> . ./person myperson Bob 43 # create a person object
$> myperson_getname # exersize an accessor
Bob
$> myperson_getAge # another accessor
43
(The shcc script is under 200 lines of source.)
For polymorphism, maybe this will serve to illustrate:
. person $args # $args is a reserved word
##---- A customer class
## Constructor
_customer() {
_person $1 $2 # inherits from person
_nAcctNumber=$3
_getAcctNumber() {
echo $_nAcctNumber
}
_setAcctNumber() {
_nAcctNumber=$1
}
##---- End of customer class
A customer can be constructed and used anywhere a person
can be used. A script can use a person, a customer, (or
perhaps a student), and ask it how old it is without
regard to actual type. I'm afraid I haven't really
conveyed an answer, and instead have illustrated only
inheritance. But I hope this partly satisfies your
curiosity.
The environment includes these after the person is constructed:
args='myperson Bob 43'
call_args='Bob 43'
myperson_nAge=43
myperson_strName=Bob
myperson_Delete ()
{
set | grep ^myperson | while read var; do
unset ${var%=*};
done
}
myperson_getAge ()
{
echo $myperson_nAge
}
myperson_getName ()
{
echo $myperson_strName
}
myperson_person ()
{
myperson_strName=$1;
myperson_nAge=$2
}
myperson_setAge ()
{
myperson_nAge=$1
}
myperson_setName ()
{
myperson_strName=$1
}
The compiled person class looks like this:
#!/bin/ksh
#
###############################################################################
## ClassFile: person.cls
## Created: Fri Nov 13 16:04:17 PST 2009
###############################################################################
ObjectId=$1
args=$@
## Constructor
eval "${ObjectId}_person() {
${ObjectId}_strName=\$1
${ObjectId}_nAge=\$2
}"
## Accessors
eval "${ObjectId}_getName() {
echo \$${ObjectId}_strName
}"
eval "${ObjectId}_setName() {
${ObjectId}_strName=\$1
}"
eval "${ObjectId}_getAge() {
echo \$${ObjectId}_nAge
}"
eval "${ObjectId}_setAge() {
${ObjectId}_nAge=\$1
}"
eval "${ObjectId}_Delete() {
set | grep ^$ObjectId | while read var
do
unset \${var%=*}
done
}"
#
# Construction
# -called when class first executes.
#
call_args=${args#*\ } # remove objname from arglist
${ObjectId}_person $call_args # Call constructor with arglist
Best regards,
--
Charles Polisher
Sidney Lambe
[delete]
>
> Shell scripting often is a purpose of its own. It's really more
> of an art form than real programming,
I have been following this thread with interest and liked the
way you handled the local gangsters.
But the above statement of yours is ludicrous. Your OS wouldn't
run without shell scripts and they are incredibly useful.
Any command entered at a shell prompt is a shell script.
At the other end of the scale, you could write a complete desktop
environment in bash that functioned as well as KDE and used a
tiny fraction of the resources.
Next to the C family, it's the most useful programming language
in the nix world.
We can get along without perl or ruby or java or slang. We can't
get along without shell scripts.
Sid
Seebs
> At the other end of the scale, you could write a complete desktop
> environment in bash that functioned as well as KDE and used a
> tiny fraction of the resources.
That is a fascinating assertion. While I certainly think that KDE, et
al., are pretty hugely bloated... It's hard for me to believe that a
shell-based solution would be competitive. I don't know that I could
be easily convinced that a shell-based window manager would be viable.
Are there any?
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Loki Harfagr
> On 2009-11-14, Sidney Lambe <sidne...@nospam.invalid> wrote:
>> At the other end of the scale, you could write a complete desktop
>> environment in bash that functioned as well as KDE and used a tiny
>> fraction of the resources.
>
> That is a fascinating assertion. While I certainly think that KDE, et
> al., are pretty hugely bloated... It's hard for me to believe that a
> shell-based solution would be competitive. I don't know that I could be
> easily convinced that a shell-based window manager would be viable. Are
> there any?
Do you mean you don't yet know Sid's ODE?
Admitted, he still didn't publish the full env. but we'll be patient.
As Sid's father put it in the awards winning "Lambe's got a shell"
"/dev/null has a dignity of its own".
Seebs
> Do you mean you don't yet know Sid's ODE?
Oh, it's okay, Sid said I could never talk to him again, I was just
asking the question of the newsgroup in general, because I think it's an
interesting one. I would be pretty sure that a shell would not be
able to compete effectively with even fairly inefficient C for something
like running a window manager.
Dominic Fandrey
> On comp.unix.shell, Dominic Fandrey <kami...@bsdforen.de> wrote:
>> Shell scripting often is a purpose of its own. It's really more
>> of an art form than real programming,
>
> I have been following this thread with interest and liked the
> way you handled the local gangsters.
>
> But the above statement of yours is ludicrous. Your OS wouldn't
> run without shell scripts and they are incredibly useful.
>
There is a slight distinction between often and always. ;)
Dominic Fandrey
> Dominic Fandrey wrote:
>> Janis Papanagnou wrote:
>>> Dominic Fandrey wrote:
>>>> I have written a framework for object oriented shell scripting.
>>>> It doesn't provide type safety or inheritance or access control,
>>>> but it has classes, objects and some other nice features like
>>>> automatic creation of getters and setters or return by reference.
>>> I think the getter and setter is the most unimportant feature in an
>>> object based approach. And all the Real OO Features are missing?
>>
>> To me inheritance and access control are only useful tools, not
>> necessary for the concept to work. Especially access control is
>> not required at all, it can completely be substituted with discipline.
>
>
>> 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.
Anyway, I added inheritance last weekend.
> ...
>
>> Do you
>> think it's possible to port Bourne Shell code or even write code
>> that works on both shells?
>
> Yes and no, depending on how your question is interpreted. Ksh is
> (as far as possible) an extension of Bourne shell (as is bash, for
> example), so quite all bourne shell programs should also work on ksh
> (or bash). Ksh also conforms to the POSIX standard. But, of course,
> backwards is not guaranteed; you cannot run a ksh program using e.g.
> the discipline function feature on a Bourne shell; Bourne shell is a
> more primitive predecessor.
The possibility of portability becomes less and less likely anyway.
One would probably have to branch it, even for a Linux system, simply
because of the tools FreeBSD offers that are not part of a common
GNU environment.
> One additional question resp. remark to your posted code; you are using
> the 'local' keyword, could it be that the freeBSD sh is actually a bash?
> You might get portability problems if you run your programs on a real sh
> in this case. Or is 'local' a keyword introduced and supported by your
> framework?
I only know what the manual page states:
HISTORY
A sh command, the Thompson shell, appeared in Version 1 AT&T UNIX. It
was superseded in Version 7 AT&T UNIX by the Bourne shell, which inher‐
ited the name sh.
This version of sh was rewritten in 1989 under the BSD license after the
Bourne shell from AT&T System V Release 4 UNIX.
It's definitely not a bash.
Regards
Dominic Fandrey
> Ed Morton <morto...@gmail.com> writes:
>
>> And what newsgroup would it be where we respond to a comp.unix.shell
>> post about someone creating an object-oriented language in shell and
>> simply ask why they didn't just use an existing object-oriented
>> language if they wanted to do OOP?
>
> I think this is a fine newsgroup for the discussion.
>
> Of course there's a big difference between inventing a new OO language
> and inventing an object oriented language for interactive scripting,
> especially if it can be mixed with POSIX shell commands.
>
Interesting line of thought. /bin/sh on FreeBSD is nigh unusable as an
interactive shell, I'm using tcsh for that, which lacks some critical
features for scripting, but is nice for interactive use.
But based on a bash or somesuch shell this would be a fine use case.
> A OO shell might be useful on the command line. If, for example, one
> could pass objects between shell commands instead of text, and where
> one can mix objects with text. Think of somelike like an object
> oriented awk (which might be built into the shell):
>
>
> grep -v 'DEBUG' <file | encapsulate oclass |\
> ooawk '{ .func && .ip->print, .date->print}' |\
> oosort .date| decapsulate | lpr
>
>
> Where oclass is an object class definition that has
> function func
> date is a timestamp. perhaps from a log file
> ip is an IP address field
Some of that stuff is possible.
encapsulate would be a constructor that
reads from stdin, builds the data structure and at the end serializes
itself (which is a single command for the entire data structure) and
outputs its serialized self to stdout.
ooawk and oosort would have to work in a similar fashion, but really
you'd just call "$ooclass.sort .date" and "$ooclass.print". So all
that piping wouldn't be necessary.
Unfortunately you'd have to create a compatible deserialize function
for every language/tool you want object oriented interaction with.
It works much better the other way, objects using command line tools.
>
> ...
>
> We just had a case where people wanted to sort by dotted IP addresses.
> It should have it's specialized print function. And oosort would know
> how to sort an IP address, a time stamp, etc.
That doesn't sound difficult.
>
> I certainly don't want to use a language like Java for one- or
> two-line shell scripts. Buf if I could mix POSIX shell with OO stuff,
> that would be interesting.
>
> AIR, others have tried OO shells. I admit I never looked into these
> in detail, but google pointed me to:.
>
> http://geophile.com/osh/
> http://mediakey.dk/~cc/bash-shell-object-oriented/
I never looked at any of that. In deed it's the first time I become
aware. I wonder will following those links enlighten my path or spoil
me forever?
I better don't look before I am done.
> You know, I often have to use perl or shell to parse log files. If
> would be nice to have an object class that one can take any log file,
> and convert a text file into a consistent data structure, thst a small
> set of tools could operate one.
What would be possible is to have a collection of useful classes that
do things like parsing and reformatting log files and including it:
. collection.sh
This way you could use these all the time.
Regards
Ed Morton
Ive never used it, but there is an OO awk out there if you're just
interested in parsing log files. See http://awk.info/?Oo.
Ed.
bsh
> ...
> Shell scripting often is a purpose of its own. It's really more of an
> 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
list.
"<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":
http://shoop.sf.net
http://cvs.sf.net/viewcvs.py/shoop/shoop/
http://telia.dl.sf.net/mirrors/debian/pool/main/s/
"shoop.sh" -- classless object orientation (introspection,
finalization, serialization, multiple inheritance) to plain sh(1)
same as above??
http://sf.net/projects/shoop/
TRACT: Jeffrey S. Haemer. "A new object-oriented programming
language:
sh".
Proceedings of the USENIX Summer 1994 Technical Conference on USENIX.
Summer 1994. Technical Conference, p.1-1, 1994-06-06P06-10, Boston.
^ http://portal.acm.org/citation.cfm?id=1267258&dl=GUIDE&coll=GUIDE&CFID=35669572&CFTOKEN=78909355
^ QT: Introduces a tiny, object-oriented programming system written
entirely in POSIX-conforming shell scripts.
"bash++.c"
http://sf.net/projects/bashpp/
"Idee Sparse Per Shell Object-Oriented"
news:it.comp.os.dibattiti
http://risitano.altervista.org
http://twiki.dsi.uniroma1.it/twiki/view/Users/NicolRisitano/
"ksh93 OOP using discipline functions"
https://mailman.research.att.com/pipermail/ast-developers/2004q3/000079.html
https://tugll.tugraz.at/ruedigers/weblog/
"woosh.bash" (NCA?)
http://themes.freshmeat.net/projects/woosh/
http://wosx30.eco-station.uni-wuerzburg.de/~martin/download/woosh-0.2.tgz
And here are two of my past contributions to C.U.S.
that are pertainent:
"OO methodology implemented through file system":
http://groups.google.com/g/d597fefe/t/ae57ec19ac3b92fb/d/c95776ae4f35d07c
"Organization of shell code function library":
http://groups.google.com/g/d597fefe/t/fe4bdf10638d6390/d/35510153455b1e3e
> 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.
Good luck!
=Brian
Janis Papanagnou
> 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.
> [...]
Janis Papanagnou
> [...]
Thanks for the links.
> "ksh93 OOP using discipline functions"
> https://mailman.research.att.com/pipermail/ast-developers/2004q3/000079.html
> https://tugll.tugraz.at/ruedigers/weblog/
The latter link seems either broken or wrong.
Any more information about it?
Janis
> [...]
Dominic Fandrey
> Dominic Fandrey <kamik...@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
> list.
> ...
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.
Seebs
> 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
idioms.
> 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:
save_IFS=$IFS
IFS=:
(do something using new IFS)
IFS=$save_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
writing:
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
familiar with.
There are some cases where an idiom is unclear.
Consider:
x=$(eval echo foo_$y)
eval x=\$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.
Kaz Kylheku
Hi Janis,
It is indeed the case that inheritance is not required for polymorphism.
Inheritance is not a requirement object-orientation at all.
The statement ``it's only a precondition if there is type safety'' is a bit
misleading. I suspect it's intended to say ``if there is compile-time typing''.
In that case the statement is in fact true.
That is to say, inheritance is in fact workaround for supporting limited
forms of dynamic polymorphism in static languages. (Inheritance is
more than that, of course, but it /serves/ this way).
In order for an X to be a kind of Y, the static language requires us
to somehow declare that type X is derived from type Y. Then we are permitted,
by the compiler, to substitute an X into parts of the program that expect a Y.
In a dynamic language, we don't need types X and Y to be related by inheritance
in order to work with the same set of methods. We can simply pass X and Y to
the same parts of the program, period. (But we may still have inheritance
because it provides useful, experssive tricks: implementation sharing,
multi-methods, ...).
But a dynamic language does not lack type safety. I, ahem, ``object'' to that.
At the barest essence, ``object oriented'' means that type is a property
of a datum, rather than of the program operating on the datum.
Further embellishments to this definition tend to be increasingly
ideological. People promoting a particular language which has OO features wll
tend to say that OO is exactly that set of features, and nothing more or less.
So idelogical definitions of OO get laced with irrelevant concepts:
``It's not OO if there is no access control''. ``It's not OO if there
is no inheritance''. ``It's not OO if there is no encapsulation''.
``It's not OO if it doesn't have a GUI builder''. Etc.
Dominic Fandrey
Even dynamic languages can offer type safety (some do so optionally, like
PHP5, at least for objects), in which case inheritance becomes necessary, too.
So my statement is valid - type safety is the hook that makes inheritance
necessary for polymorphism.
Of course, static languages always have type safety, so I agree with
everything else you say.
Just look at Python, polymorphism without inheritance is quite common
there. Programmers just expect people to use their code with objects
conforming to the expected interface, which is as I understand it,
what you are talking about.
bsh
> bsh wrote:
> > Dominic Fandrey <kamik...@bsdforen.de> wrote:
> > > ...
> 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.
This deserves a response -- peace! I was in no way being
sarcastic or duplicitous. Your English is most certainly better
than my German, especially as you mention that you've not
practised English in a native English-speaking country,
which I suspected.
Don't think of me as being patronizing if I take the opportunity
to mention Heiner Steven's "translate" script to translate
from English to German. HS runs the pre-eminent site for shell
scripting: shelldorado.com.
"translate.sh":
http://shelldorado.com/scripts/quickies/translate.txt
Nowadays, dictionary.com is probably a better resort.
> > 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
> > list.
> > ...
> 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.
Two or three weeks? Again, I am sincere in my surprise
insofar as I have been working on certain non-trivial scripts
for more than a decade -- for my shell IDE, as mentioned.
Being a compiler/language designer, I do program in O-O
low-level languages, including Java and C++, so I know the
paradigm of O-O design and implementation; however, I have
no experience in ksh93t+ O-O programming. I stopped developing
a O-O framework of my own, presumably much like yours, when
O-O in ksh93 become available, but programming or using one
will be invaluable for my function library and framework within
my IDE.
It seems like your framework is to shell as (older) "dynace"
was to C: a intermediate (and fairly successful!) attempt to
hack a language into a O-O paradigm. I programmed in this
when C++ was still new -- and buggy.
"dynace.c": "DYNAmic C Extension" -- O-O enhancement to C
http://algorithms.us/software/
Perhaps you would like to repost your query to the
development team and forum for ksh93 and utilities? A
list from most to least pertainent is:
"shell-discuss Mailing List":
http://opensolaris.org/mailman/listinfo/shell-discuss
https://www.opensolaris.org/jive/forum.jspa?forumID=138
"ksh93-integration-discuss Mailing List"
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/
^ Also: https://www.opensolaris.org/jive/forum.jspa?forumID=103
"AST-developers Mailing List"
https://mailman.research.att.com/pipermail/ast-developers/
"AST-users Mailing List"
https://mailman.research.att.com/pipermail/ast-users/
=Brian