Re: [gentoo-dev] initscripts in python

[merv]

Yep, one of the things that would be hard to do would persuade many 
of either the *need* for this or of its advantage.

To move away from pros and cons for a moment, I see a need and an 
advantage :

[*need* is a word treated as meaning a potential *use for* something, 
for now, a bit elastic perhaps]:

1) [need or use:] by incorporating Python functionality (or other 
programming lang) into a more extensible style shell, sh becomes 
more widely accessibly to a number of community member who have 
minimal->no sh scripting ability, but who are familiar with programming 
of one flavour or another. I would have to agree, and say that my first 
impulse is to just encourage them to learn to *bash* or whatever, but 
everyone has their reasons.  If a user was able to incorporate the 
functionality (but not the whole language) of a lang with which they 
were familiar (or their favourite lang) at build time, shell scripting would 
become a common language for even more people of the Gentoo 
family.

2)[advantage or effect:] to undertake such a re-write of the way that the 
shell is built would, conceivably, result in a change in the way that the 
community thinks of the shell.  Perhaps shell extensibility (for which I 
mean a kind of individual user-level customisation during build) would 
result in the shell itself being perceived as a kind of IDE or runtime 
environment, as well as a way to get around and make things happen.  
This kind of *shell development* might act as a corollary to kernel 
development. If kernel development is seen as cultivating and 
extending the functionality and capability of the kernel, then perhaps 
shell development could be seen as refining and extending the 
adaptability and usability of the shell at the level of the individual user, 
providing greater choice and customisability.  Would this not be a 
natural implementation of the kind of hyper-tweak choice-driven 
philosophy of Gentoo?

and of course, any extensibility options to be built in at build-time could 
of course be ommitted (packaged as *default off*), only turned *on* by 
those who deliberately wanted to make use of it.

It has always felt to me that the power of sh scripting was its flexibility. 
To extend the functionality of the sh-scripting env in this way would 
consolidate, in my view, the usefulness of sh-scripting by enhancing it, 
or at least extending it for those who wanted to make use of it.


>SH-scripting is in itself already very powerfull. It's not because lots of
>initscripts are bad written (because of historic reasons) that it is to
>blame
>on sh. You can create functions with sh. You can do so many
>powerfull things
>with it (no, object oriented programming it cannot, but that's not
>powerfull
>either :)
>
>http://www.tldp.org/LDP/abs/html/complexfunct.html
>
>Not that I dislike Python, au contraire, I like the immens easiness for
>parsing XML with it, controlling databases with the DB-API... but
>initscripts
>don't require this possibility.
>
>	Sven Vermeulen
--
	Fighting for peace is like fucking for virginity.
-
Merv Hammer
mailto: merv@×××××××××××××.cy

--
gentoo-dev@g.o mailing list