i thank you for your thoughts and the time you took to "pen" them.
my thesis was in regard to the documentation_set for sh(1).
what i said about my "killer_app"
was an effort to describe my motivation for examining that set.
while it was not my intention to
seek advice regarding the development of my prototype,
i appreciate your efforts, on my behalf, and will respond to them,
in addition to your thesis_related comments.
Oliver Fromme wrote:
hear !
hear !
> Another possibility is to use cpp (the C preprocessor).
oddly enough, i thought of this approach first [ great minds think alike ].
i rejected it because of the work involved to create work_arounds;
its intended use is enough different from mine.
> It's not perfect either, but maybe it's more suitable
i already did the filter thing:
foo=`echo FreeBSD | right_all_but_n 4 | left_n 3`
or
foo=`echo FreeBSD | right 3`
where "left_n", "right_n", "left_all_but_n" and "right_all_but_n" are
compiled, c_language filters, which take the character_count as an argument.
i may end_up using it, for now, because it works and it is "intuitively obvious".
long_term, however, i will reject it, because it forks a child.
additionally, the use of dd(1), especially for my target user_base,
violates a corollary of my stated commandment,
which i did not state originally, but, which i will state here:
thou shalt not be clever.
some folks see commandments as "negative rights".
a "positive rights" variant would be:
thou shalt be intuitively_obvious to even the most dis_interested reader;
however, this is not as clear, so, it is not used, except informally.
>
see note [c].
Whether this is faster or slower I can't tell, it
"abuse", to me, is a subjective term, because
sh(1) "kinda is" and "kinda isn't" a programming language.
it has an intended purpose, but, it will do many other things, as well.
In that case you're advised
when i discovered python, about eight or nine years ago, i got really excited.
it would have been my first choice, for many reasons, but,
i was forced to reject it because it violates another commandment:
thou shalt not preclude the use of arbitrary white_space between tokens.
my writing_style violates python's indentation rules.
there exists a related rule:
thou shalt formally specify the syntax of thy token_set.
this comes under the commandment:
the operation of thy app shall
produce the least amount of astonishment in thy user.
the syntax
name=value
can not have white_space around the equal_sign.
it is hard_to_read.
an sh(1)_newbie with programming_language experience will be, probably, taken_aback.
however,
setvar name value
can have arbitrary white_space.
betcha can't guess which one i like.
ruby forces me to be "oopsy".
fifty years ago, my late mommy taught me that it isn't good to be "oopsy".
the problem with "oops" is that, for my purposes,
it is not "overkill", it is "too much overkill".
it is my understanding that it --does-- have a clear advantage in one case:
the development of a so_called "windowing graphical_user_interface"
[ if anyone knows of another, please advise ].
"oops" is like socialism:
in the faculty_lounge, it seems like a really_great_idea
[ "will you have another glass of chablis, professor_emeritus ?" ];
in the real_world, it gets in the way of those who do real work.
i discovered perl in 2000, just before i discovered python.
perl is clever.
perl's numbers are floating_point; mine are integers
[ i understand that an integral number_type has been added, but,
this does not address the main problem
].
>
i am not up to seven, yet
[ i have the cds from the mall; so many tasks, so few hours ].
eight is not out.
i can not expect my users to always have the "latest_and_greatest".
this is why, eventually, i will have to write most of this in c.
>
not that i have not discussed.
>
i have about twenty shelf_feet of books, just on computer_software topics.
i do not like "online" books, because i stare at my screen enough, as_it_is.
there is absolutely nothing like
a good book,
a comfortable chair,
a high_wattage incandescent_lamp [ evenings ]
[ to provide flicker_free even illumination that is easy_on_the_eyes ],
a fine dominican cigar and
artur schnabel, emil gilels or alfred brendel playing beethoven on the hi_fi.
oh, yes; i turn off the phone.
>
ah_ha, you have arrived at my thesis.
the man_page author states that it is not complete, in the first paragraph.
>
i am not referring to any "developers".
a statement in the "tour" asserts that it remains as an introduction.
clearly, this document is intended to be a quasi_tutorial for
a reader who is experienced in one_or_more other areas.
the information that it contains should be in the source_code,
where it has a higher probability of being more recent,
relative to the source being compiled
[ as i said originally, this may be the case,
for i have not, yet, reviewed all of the source
].
>
this does not qualify;
converting from 32_bit to 64_bit occurs platform_wide,
which is a task that will take a_while.
a change that applies to all shells also does not qualify.
or a new builtin. Sometimes a
this qualifies, because it is sh(1)_specific.
And sometimes bugs are fixed, of
sh(1) has bugs ?!?!?!
holy moses !!!
next thing, some_one will tell me that vi(1) has bugs.
>
to you, sir, as well.
it has been a pleasure typing with you.
