Date: Tue, 28 Jul 2009 21:14:41 +0100 From: spellberg_robert <emailrob@emailrob.com> To: fbsd_chat <freebsd-chat@freebsd.org>, Oliver Fromme <olli@lurza.secnetix.de> Subject: [ fbsd_chat ] Re: sh(1) documentation_set Message-ID: <4A6F5C31.2000502@emailrob.com> References: <200907281352.n6SDqXur017295@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
dear mr. fromme ---
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:
> spellberg_robert <emailrob@emailrob.com> wrote:
> > my killer_app, -- a priori --, depends upon
> > the use of a good general_purpose macro_processor [b].
> > i thought that i had found one in m4(1),
>
> Personally I think m4 is weird and error-prone.
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
> for your purpose.
>
> > therefore, i re_evaluated the use of sh(1).
> > it will do almost everything that i want, excluding, specifically,
> > a] sub_stringing by character_count [c];
>
> You can define a shell function that uses dd(1):
>
> $ substr() { echo "$1" | dd bs=1 skip=$2 count=$3 2>/dev/null; }
> $ foo=`substr "FreeBSD" 4 3`
> $ echo $foo
> BSD
> $
>
> It's not terribly efficient, because dd(1) is an external
> binary that has to be exec*()ed by the shell. So it might
> be slow if you use the substr function often.
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.
>
> It is possible to write this function using shell-builtin
> commands only (no exec*() necessary), but it requires a
> loop.
see note [c].
Whether this is faster or slower I can't tell, it
> probably depends on the circumstances. Shell loops that
> use only builtin features are usually fast enough for
> normal script, unless you try to abuse sh(1) and use it
> like a programming language.
"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
> to use something better suited for the purpose, like
> Python (my personal favourite), Ruby, Perl or similar.
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
].
>
> > b] arithmetic on integers, of width 37_bits or so [ let's say, 40 ];
>
> This has been improved. Recent versions of FreeBSD 7 and 8
> use 64 bit arithmetic, like most other shells.
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.
>
> > c] more_than_minimal string conditionals
> > [ "test" is, understandably, file_oriented ].
>
> There is also expr(1) and other tools. Apart from that,
> you should be able to implement what you need with shell
> functions. Is there anything in particular that you are
> looking for?
not that i have not discussed.
>
> > i do not expect a man_page to be a tutorial,
>
> Right. Man pages are reference documentation. They're
> not typically used for tutorials, recipes or "how-to".
> There are quite many books on the topic of bourne shell.
> (I mean real books, i.e. paper ware. There might be
> online books, too, but I'm not aware of a good one right
> now that I could recommend.)
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.
>
> > man_pages need to be, at least, "substantially_complete".
>
> I agree that the sh(1) manual page should be complete,
> and I think it is indeed complete. Do you think some
> piece of reference information is missing?
ah_ha, you have arrived at my thesis.
the man_page author states that it is not complete, in the first paragraph.
>
> > second, i can understand the "tour" being out_of_date somewhat,
> > perhaps, even by a few years,
> > but, --twenty-- years ?
>
> Probably it is kept only for historical purposes. The
> developers working on the sh(1) source certainly don't
> need that "tour" file.
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
].
>
> > i could be wrong, but,
> > i suspect that sh(1) doesn't change much from year to year.
>
> Well, it depends on what you call "doesn't change much".
>>From time to time it grows a new feature (like the 64bit
> arithmetics last year)
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
> builtin is even removed, like the printf command which
> used to be builtin, but was removed in favour of the
> external command.
this qualifies, because it is sh(1)_specific.
And sometimes bugs are fixed, of
> course.
sh(1) has bugs ?!?!?!
holy moses !!!
next thing, some_one will tell me that vi(1) has bugs.
>
> Best regards
> Oliver
to you, sir, as well.
it has been a pleasure typing with you.
rob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A6F5C31.2000502>