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 <rweikusat@mobileactivedefense.com>
Newsgroups: comp.os.linux.development.apps
Subject: Re: UNIX(*)/ Linux history & system design
Date: Fri, 09 May 2014 17:57:12 +0100
Lines: 88
Message-ID: <87fvkic2l3.fsf@sable.mobileactivedefense.com>
References: <limvgj$tse$1@dont-email.me> <ljdbhe$ol8$1@dont-email.me> <87k3adxomn.fsf@sable.mobileactivedefense.com> <ljg06q$f5s$1@dont-email.me> <87wqear01o.fsf@sable.mobileactivedefense.com> <ljl6uh$rbi$1@dont-email.me> <874n1dwvo0.fsf@sable.mobileactivedefense.com> <87zjj5vf1k.fsf@sable.mobileactivedefense.com> <ljnp3t$ni7$1@dont-email.me> <87k3a0q867.fsf@sable.mobileactivedefense.com> <lk91qa$9l3$1@dont-email.me> <lk965t$3o3$1@dont-email.me> <lka3vv$r0j$1@dont-email.me> <87zjivatio.fsf@sable.mobileactivedefense.com> <lkchdq$jqn$1@dont-email.me> <87a9atpq7y.fsf@sable.mobileactivedefense.com> <lkdoa0$t83$1@dont-email.me> <87ha51nvzw.fsf@sable.mobileactivedefense.com> <lkfj95$s1o$1@dont-email.me> <87fvkkifth.fsf@sable.mobileactivedefense.com> <lki58c$9kf$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net XQiOjsykeb4iImCxSNpH3AOBcC2BkYqSlF9LgLh/s7c605l80=
Cancel-Lock: sha1:jfKpVAcaPRZAOGwAAggUTMOkNK0= sha1:zrbGiSXd9O6lUI3Lp4cZ+BWSnZc=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Xref: csiph.com comp.os.linux.development.apps:730

crankypuss <crankypuss@nomail.invalid> writes:
> On 05/08/2014 07:02 AM, Rainer Weikusat wrote:
> <snip>
>
>> 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).
>
> The simple fact that getopt supports different "scanning modes" and
> "compatability" levels is imo sufficient evidence to support the
> assertion that it is not (or perhaps, "no longer") what is needed.
> That different core commands support different methods of specifying
> options (some require "=", others not, etc) supplies the gravestone
> imo.

There's sort-of a proverb in German which roughly says that two
professors might possibly agree on anything except the proper
rules for using quotations. Consequently, software developed by
different people will tend to use different conventions for interpreting
positional arguments. This is especially true when different development
philosophies clash with each other, eg, when ex-LISP-hackers start to
implement a "complete Unix-compatible software system" to "give it away
free to everyone who can use it". Depending on one's personal
standpoint, the result is either "software which is much more useful and
user-friendly" or "bizarre, non-standard extensions".

Wrt getopt, I'm leaning towards the 2nd standpoint because "a 'perfect'
but complicated to use universal system for parsing command-line
arguments" puts too much emphasis on a tangential problem for my taste
and I am willing to make 'usability compromises' if this enables me to
get to writing actually useful code, instead of 'command-line argument
parsers', quicker (and there is no such thing as 'the perfect XYZ' in
software, anyway, it all comes down different tradeoffs). Because of
this, I

was_posixly = getenv("POSIXLY_CORRECT") != NULL;
if (!was_posixly) {
	rc = setenv("POSIXLY_CORRECT", "1", 1);
	rc != -1 || sys_die("setenv");
}

[...]

if (!was_posixly) unsetenv("POSIXLY_CORRECT");

as needed and accept this as part of the inevitable complications
arising in a complex world.


>>> 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
>
> There are levels of scripting.  Basic scripting provides for the
> repeated issuance of one command using various plug-in arguments, for
> issuing a fixed sequence of commands that is abbreviated by the
> script, or some combination of the two.
>
> The bash "language" is imo suitable for only that most basic level of
> scripting, and barely that.

That you insist on confusing the Bourne shell (not 'bash', that's the
'Bourne Again Shell' and sports the usual GNUism of supporting
everything in three different ways and two kitchen sinks just to be on
the safe side, ie, it has A LOT more features', eg, arrays, builtin
support for arithmetic operators and lexically-scoped variables, to name
just a few) with a cpp-style macro preprocessor doesn't mean you're
right about that.

> It was imo a serious error to make the decision that a "shell"
> supporting various control characters that are useful in an
> interactive mode should support those control characters via the
> "language" rather than the interactive portion of the shell.  The
> result of that decision makes the syntax of the "language" common, but
> at the cost of reducing the readability of non-interactive code.

To me, the readibility of Chinese is zero. But this doesn't mean Chinese
can't be read, only that I can't read it.