From: Fabio Massimo Di Nitto <fabbione@ubuntu.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [RFC] cleaning up inconsistent usage of perl, python and sh/bash
Date: Mon, 12 Nov 2007 09:51:57 +0100 [thread overview]
Message-ID: <4738142D.7090803@ubuntu.com> (raw)
Hi guys,
usual round of clean up.. we are way too inconsistent in the way in which we
invoke perl, python, sh and bash
For example: perl vs perl -w, /bin/sh vs /bin/bash and so on.
I would like to address it by:
- make all paths to perl configurable. There is no guarantee that the user wants
to use the default perl installation. Default to /usr/bin/perl.
- switch all perl scripts to use -w when building in debug mode as it did
uncover bugs before and it will enforce a round of tests on all perl scripts.
Default: no -w for release build (to switch permanently on once we can give all
the scripts a test run).
- (optional) make sure all perl scripts use strict;
- make all paths to python configurable. There is no guarantee that the user
wants to use the default python installation nor the default version.
- make all paths to the default shell configurable. We can only rely that
/bin/sh exists, but there is no guarantee that it is bash. I assume that most
scripts requires bash so we want to make the path to bash configurable as we
don't know if the user wants the default instance of bash in the system.
- switch all bash invocations to use -e by default.
- (optional) switch all bash invocation to use -x when using --debug_shell
configuration option.
As a consequence we can:
- simplify def2var script to do the right thing by parsing the first line of the
TARGET
- simplify make/fence*.mk into one invocation.
Please let me know what you think and I will start to work on this.
Cheers
Fabio
--
I'm going to make him an offer he can't refuse.
reply other threads:[~2007-11-12 8:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4738142D.7090803@ubuntu.com \
--to=fabbione@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.