Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system Subject: Re: UNIX(*)/ Linux history & system design Date: Thu, 08 May 2014 14:02:34 +0100 Lines: 188 Message-ID: <87fvkkifth.fsf@sable.mobileactivedefense.com> References: <87k3adxomn.fsf@sable.mobileactivedefense.com> <87wqear01o.fsf@sable.mobileactivedefense.com> <874n1dwvo0.fsf@sable.mobileactivedefense.com> <87zjj5vf1k.fsf@sable.mobileactivedefense.com> <87k3a0q867.fsf@sable.mobileactivedefense.com> <87zjivatio.fsf@sable.mobileactivedefense.com> <87a9atpq7y.fsf@sable.mobileactivedefense.com> <87ha51nvzw.fsf@sable.mobileactivedefense.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net 5n1eEgKI3his9nUHc3zM9AhrUHEBfAbQAo0nOji5X7cUNZJ6I= Cancel-Lock: sha1:lMf4pvfrT8oZSWXqkETul9qH+3M= sha1:HrD5KtnW3MJo5KY+YCvVfTYBcws= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.apps:727 comp.os.linux.development.system:697 crankypuss writes: > On 05/07/2014 03:01 PM, Rainer Weikusat wrote: >> crankypuss writes: >>> On 05/07/2014 09:23 AM, Rainer Weikusat wrote: >> >> [cross-posted to colda with follow-up to, as this is not really about >> system development[*]] > > Actually it rather is, but clearly you do not see it that way; > apparently you are able to look at "bash scripts" that are part of the > init system, and "bash scripts" that are divorced from the system > insofar that they do not participate in boot-manager setup (cf grub2) > or similar functions, without seeing that they are in any way similar. Something like this was my idea when I changed the subject. But since the topic has shifted more towards 'apply something to some use' and I'm actually doing 'application development' and not 'system development' (except when necessary/ unavoidable) and consequently, use the shell rather for that (and some people staring making annoyed noises I sort-of understand [or believe to do so] ...) ... > >> [*] It is not terribly on topic, there, either, but 'shell-related >> groups' tend to be inhabited by 'strange people' solely busy with >> telling others why the shell mustn't be used (a la 'in 1492, on a >> DUCStation Donald running Infrix PI - 12, /bin/sh was really a hard link >> to /usr/ucb/bbc/cia/doa, therefore, this code is not only not portable >> but will actually cause a major earth quake in California' ...) and I'm >> more interested in 'using the shell to develop actual applications' than >> 'Klingon-quoting in hostile environments' ... > > Oh look, it has called me "strange", what a quaint and helpful > introduction, thank you ever so much! I didn't address anyone personally and actually consider 'behaviour of people belonging to recognizable groups' generally strange, eg, "on weekends, this pub is populated by strange people who seem to enjoy making loud, ugly noises aka 'shouting' very much (at least, they keep doing this for some inexplainable reason), seem to enjoy drinking until they can't walk straight anymore (I can understand the first part but not the second: As soon as this starts to happen to me, and usually, I avoid that, I'm obviously having a technical problem and should go home before I trip over a kerbstone and break a leg or something like this) and who don't ever seem to get much beyond being an arbitrary appendix of their own sex life (I'm totally flabbergasted that they're apparently never bored by this topic)". Computers are easier to deal with: They usually don't resort to violence when they feel mistreated, hence, "how to avoid mistreating them" can be determined by experiments. > >> [bourne shell language] > > following from RW: >>>> In addition to constructs specific to its purpose, ie invoking >>>> programs, possibly, programs cooperating in a pipeline, it supports the >>>> usual syntactic constructs available in 'pre-OO' high-level languages: >>>> Three kinds of loop ('loop while a condition is true', 'loop until a >>>> condition becomes false', 'loop over the elements of a list'), loop >>>> control statements ('break' and 'continue'), conditionals (if .. elif >>>> ... elif ... else, a 'case statement' and the possibility to create >>>> named subroutines (but not lexically-scoped variables, although bash has >>>> them as an extension). It doesn't use braces as universal block >>>> delimiter but keywords depending on the 'block construct' being >>>> used. For loops, thats do .... done, for if then ... fi and for case, it >>>> is case ... esac. The latter two pairs are Algol-68 influenced, >>>> presumably, because Steve Bournce (author of the original Bourne shell) >>>> was very fond of that. It doesn't support named parameters for functions >>>> (or scripts), only positional ones. While I wouldn't to use it (in case >>>> suitable alternatives are available) for something larger than at most a >>>> few hundred lines of code[*], it is a perfectly usable programming language >>>> and often, a very easy to use one. >>>> >>>> Would you care to elaborate why precisely you consider it to be 'so >>>> crude that it is astonishing it didn't vanish'? >> >> [...] > > from C (the first elaboration): >>> Only positional parameters for functions, > > from RW: >> There are (to the best of my knowledge) the following models for dealing >> with 'parameters passed to something' >> >> - assign passed parameters to predefined 'parameter names' 'by >> position', possibly with support for optional or 'default >> value' arguments >> >> - parameters are passed in form of 'key/value'-pairs where the >> 'key' designates the name of a possible input parameter and >> the value its value >> >> - access passed parameters by position [...] >> The third is the most general as it can> be used to emulate the >> other two, [...] > from C: > > It's a shame that at one level or another we are all surrounded by > things we don't truly understand. > > In regard to a shell language, one should (imo, of course, which you > have already implied is "strange") perhaps consider the actual form of > the 'nix command string, which provides for the passing of both > arguments and options, in other words, positional parameters > (arguments) plus key/value pairs (options of the short or long > flavor), as appropriate to the function performed. I think I already wrote that: An ordered sequence of arguments can be interpreted as 'positional argument list' or 'set of key/values pairs' or both. 'getopt' is both a C library routine and available to 'shell scripts and functions defined by them' (I think the lack of both lexically scoped parameters and lexically bound dynamic parameters is a much graver deficiency, at least theoretically). > You might also consider the possibility that a "functional" script, > that being one which is called to perform a specific function and > passed whatever parameters are appropriate to that function, *might* > benefit from being able to return data to its caller beyond a simple > exit-code and whatever possibly-parseable string data it has written > to stdout or stderr, a "result" that does not have to be parsed by Whatever facilities might be available in a given environment, they could always be improved ... > something as crude as 'sed' in order to obtain an approximation of > what could simply be returned. ... by adding missing functionality. Eg, a C function can 'simply return' any C type or a pointer to a C type, however, if that is supposed to be written to a file in order to be processed next week or on a computer in Tierra del Fuego, the ability to serialize and deserialize a complex data structure could also be very helpful. In general (truism ahead), different programming environment provide different features and usually, lack some other features. And "weeping oneself into sleep because reality is much more harsh and ugly than one would like it to be" usually doesn't accomplish anything. >>> no builtin functions to speak of, which drives the user to >>> using sed or some similar external program for even trivial >>> functionality. >> >> The main purpose of the shell is to provide facilities for invoking >> external programs within a 'global control context' supplying the >> facilities for using these 'library routines' in order to solve more >> complex problems than what could be done with them in isolation. [example program with explanation] >>> It's a very basic script processor, not a language. >> >> The 'shell program' is an interpreter for 'the shell language'. > > I am constantly amazed at the way some can, through the tunes of the > unthought words they parrot, consistently hide what is not there by > covering it with popular illusion. I'm pretty certain that you never heard anyone speak to me, hence, you cannot possibly know what I might or might not have heard elsewhere, and you certainly can't read my mind, hence, you know nothing about 'my thoughts' (or lack thereof). >>> On top of that, the bash rules for escaping the characters it has >>> coopted for special purposes make it a syntactic nightmare even worse >>> than C. >> >> In theory, yes. In practice, "it can be dealt with", especially >> considering that a lot of 'shell code' is supposed to operate in a >> rather controlled environment. > > Yes, it is sometimes possible to use a three-headed hammer to adjust a > watch. An interpreter is not a hammer and 'adjusting watches' not something programs usually do, IOW, this doesn't really communicated anything except that you're strongly convinced that something I consider to be 'fit for purpose' (for some purposes) because of in depth practical experiences with it isn't really 'fit any purposes' and you rejected it almost outright because of this (earlier, you wrote that you had written 'exactly one shell script'). That's your prerogative but I disagree with it.