Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.system,comp.os.linux.development.apps Subject: Re: UNIX(*)/ Linux history & system design Followup-To: comp.os.linux.development.apps Date: Wed, 07 May 2014 22:01:55 +0100 Lines: 118 Message-ID: <87ha51nvzw.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net ZpTzNDkiojzueOsZPOmXhQte0/yqezUhfNatiKaCXmf+w+ILA= Cancel-Lock: sha1:9ca/5PDLAGzgdtYaKqIpEJcnO1I= sha1:6kDXeaPYmzcWTXGyOjDtDzILDMA= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.system:694 comp.os.linux.development.apps:725 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[*]] [*] 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' ... [bourne shell language] >> 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'? [...] > Only positional parameters for functions, 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 first is the one which is most common (nowadays) and it has the nice property that 'correctness of calls' can be checked statically. OTOH, it is also the least flexible one. The third is the most general as it can be used to emulate the other two, either by assigning 'passed parameters' to 'input parameters' based on position or by interpreting them as key/value pairs. But it needs explicitly written 'parameter parsing code' which also needs to determine if the call was sensible/ correct at all. This model is not only also used by 'C programs' (and - more generally - by anything executed via an exec*-function) but also by some other programming languages, presumably, because these were influenced by the shell, notably, Perl (the largest individual Perl program I'm presently dealing with has 15,666 lines of Perl code and a few thousand more in auxiliary modules so this is a perfectly workable model). > 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. Eg, a Bourne shell program for printing the numbers from 0 to 9 could be n=0 until test $n -gt 9; do echo $n n=`expr $n + 1` done this uses three 'external commands', test which performs some kind of test and signals the result via its exit code, echo which prints its arguments and expr which evaluated an arithmetic expression and prints the results. All three may also actually be 'shell builtins' as an optimization/ performance hack at the expense of some loss in flexibility eg, at some time in the past, I was using an expr with support for floating-point arithmetic. This wouldn't work for a shell builtin. > It's a very basic script processor, not a language. The 'shell program' is an interpreter for 'the shell language'. > 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. > The fact that someone kludged control structures onto a simple > substitution engine does not make it a programming language. Whether or not something constitutes 'a general-purpose programming language' is a technical question which can be answered objectively ("Is it turing-complete?"). That's not at all related to the question if the programming language is actually useful in practice or who might like or dislike it for whatever reasons.