On Thu, Feb 20, 2020 at 12:07:58AM +0000, Aaron Sloman wrote:
>
> In part, all of this was required to allow the 'end' scripts to work with
> different combinations of hardware (e.g. sun, dec, hp (hp_ux?), ibm,
> mips, and others) and operating systems (e.g. vms, unix, sunos, solaris,
> aix, ... linux).
>
> I think the ability to source intermediate files allowed much less
> cluttered final scripts, and also allowed changes of a particular sort to
> be made in one location and inherited in several locations.
>
> I don't think anyone outside the Sussex and ISL development teams ever had
> a complete overview of the network of dependencies -- used by John Gibson
> to produce a single source tree where code for any combination of hardware
> and software could be found by following appropriate branches of the tree.
>
> Poplog scripts originally used the old unix shell which became csh then
> tcsh and I still use it.
>
> However, the bourne shell was developed a bit later and that became sh then
> bash (and variants) and is far more widely used, with suffix '.sh' to
> ensure there's no confusion.
>
> I think we have to preseve some of the duplication for users who make use
> of csh/tcsh, otherwise I would propose removing the duplication.
>
> If we switch to using *only* sh (bash) scripts, then anyone wanting to
> invoke poplog from tcsh would first have to run bash, then after all scripts
> have been source run tsch and then invoke poplog.
>
> Perhaps that should be done at some future date, but at present the network
> of scripts supports both sorts of poplog user, and should probably be left
> unchanged, until people like me no longer exist...
Sorry for saying that, but I think that this maze of scripts is
both unmanagable and completly unnecessary. Currently Poplog
sets of order of hundred variables in user environment. First,
there is no reason to clutter user environment with Poplog
variables, Poplog should obey variables set by users, but
otherwise use sane defaults. Second, if there is need for
user code to parametrize (customize) Poplog behaviour, this
should be done via Poplog code not via shell scripts.
Some shell scripts may be needed, but there is no need
for users to source them, so it is enough to provide
Bourne shell scripts.
AFAICS current system is inefficient, inflexible and hard to
maintain. Concerning inflexible: there are many points
which can _theoretically_ be used to change Poplog behaviour.
In practice choosing wrong point leads to more or less
wrong behaviour. Scattered and hidden dependencies make
it hard to find correct change point.
--
Waldek Hebisch
