80x24.org misc. Free Software, open data formats/protocols discussion
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: misc@80x24.org
Subject: why I prefer scripting languages
Date: Sun, 14 Sep 2014 22:36:48 +0000	[thread overview]
Message-ID: <20140914223648.GA31961@dcvr.yhbt.net> (raw)

(totally genericized version because I've done the same thing
 countless times)

Last night I encountered a weird (and annoying) warning message from a
script I run occasionally.  Said warning message was kind enough to tell
me which file it was from, and it was not from the main script itself,
but one of the libraries (also a script) it was using.

I decided I wanted to prevent the main script from triggering the
warning in the library script.  Fortunately, I happen to be the
administrator of the machine I was running on, so I:

	1) opened the library script in my $EDITOR (requiring sudo)

	2) find the offending warning message in the library script

	3) lightly-edited the library script to dump a backtrace
	   before the warning message, this is a one or two-liner[1]

	4) rerun my main script to trigger the backtrace, and
	   note how the main script triggered it

	5) workaround the warning fix the bug in the main script

	6) undo my edits (made as root) to the library script

	7) send resulting the fix in the original script to the
	   maintainer(s)

The whole process took less than a minute and I never left the
original terminal I was working on.  No waiting for any source
code to download, no waiting for building or linking, etc.

Had I been using a compiled language, I would've done the same thing.
However, it would've taken longer to download all the required
components, wait for things to build, install the temporary package[2]

So yes, keep your software easy for ordinary users to hack on.


[1] in Perl: use Carp qw(cluck); cluck("warning here!")
    in Ruby: warn caller.join("\n")
    # sorry, haven't touched Python in over a decade,
    # comments greatly appreciated

[2] That said, Debian GNU/Linux (my distro of choice)
    makes it easy (but still potentially time consuming) with:

	# install build-dependencies as root
	sudo apt-get build-dep $PACKAGE

	# download the source to $PWD (no need for root)
	apt-get source $PACKAGE

	cd $SRCDIR # the above command will tell you $SRCDIR

	# make edits (no need to be root)
	$EDITOR /path/to/file/with/warning/message

	# compile + link the package
	debian/rules build

	# package it up as .deb files
	fakeroot debian/rules binary

	# install resulting debs
	sudo dpkg -i $NEW_DEBS # the above command will tell you names

                 reply	other threads:[~2014-09-14 22:36 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=20140914223648.GA31961@dcvr.yhbt.net \
    --to=e@80x24.org \
    --cc=misc@80x24.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).