Re: splitting off shell test framework
On Thu, Aug 24, 2017 at 12:23:05AM +0100, Adam Spiers wrote:
> > [1] I actually keep a local archive and convert public-inbox URLs into
> > local requests that I view in mutt.
>
> Sounds like a neat trick - any scripts / config worth sharing?
It's probably too specific to my setup, but here it is anyway.
I keep the archive in a normal maildir, which I index with the mairix
tool (you could do the same thing with maildir-utils or notmuch). New
messages get put into the maildir by mutt's auto-move feature after I've
read them.
Then I have a few keys bound in mutt:
macro pager,index M 'gmane'
macro pager,index B 'rmairix-gmane'
(you can tell from the names that these predate public-inbox entirely).
The "gmane" script just opens a browser pointing to the current message
in the archive, from which I then 'y'ank the URL into the clipboard or
pasting. The network round-trip was necessary for gmane, since the
article ids were not predictable. For public-inbox, it's not necessary,
but old habits die hard (and it's a nice cross-check that the link
you're sending out isn't broken).
Here's that script:
-- >8 --
#!/bin/sh
mid() {
exec webview "http://public-inbox.org/git/$1";
}
article() {
exec webview "http://public-inbox.org/git/?q=gmane:$1";
}
find_mid() {
perl -ne 'if(/^message-id:\s*<([^>]+)>/i) { print $1, "\n"; exit 0 }'
}
case "$#" in
0) id=`find_mid`
case "$id" in
"") echo >&2 "fatal: unable to extract message-id from stdin"; exit 1 ;;
*) mid "$id" ;;
esac
;;
1) case "$1" in
*@*) mid "$1" ;;
*) article "$1" ;;
esac
;;
*) echo >&2 "fatal: don't know how to handle $# arguments"; exit 100 ;;
esac
-- 8< --
The "webview" command is just a personal wrapper that decides which
browser to use. You could replace it with "firefox" or "chromium" or
whatever.
The "rmairix-gmane" script picks out gmane/public-inbox references and
re-opens them in mutt. It looks like this:
-- >8 --
#!/usr/bin/env perl
use URI;
use URI::Escape;
if (@ARGV) {
show_gmane_article($_) foreach @ARGV;
}
else {
while(<>) {
if (m{http://[^/]*gmane.org/[-\w/.]+}) {
show_gmane_url($&);
}
if (m{https?://public-inbox.org/git/([^/]+)}) {
show_mid(uri_unescape($1));
}
}
}
exit 0;
sub show_mid {
system("rmairix -t m:" . quotemeta(shift) . " ) {
chomp;
my ($nr, $mid) = split / /, $_, 2;
return $mid if $nr == $want;
}
}
sub extract_article {
my @path = URI->new(shift)->path_segments;
# first one is always empty in absolute URL
shift @path unless length($path[0]);
# group is always next
my $group = shift @path;
# and then look for numbers starting from the back. E.g.,
# focus=N for threads, or just "N" for articles
while (@path) {
local $_ = pop @path;
return ($group, $&) if /\d+/;
}
return ($group, undef);
}
-- 8< --
The two extra bits you'd need are:
- the ~/.gmane-to-mid.gz mapping. I don't remember if I made this
myself or stole it from one that Eric posted. I'm happy to share if
anybody wants it.
- rmairix is a personal wrapper around mairix that ssh's to my imap
server to do the search and then starts mutt on the result.
Naturally I also use it for general queries like
rmairix -t f:peff sanitize thread
I hope that helps. I suspect it may be more useful to people as
inspiration and not as running code. I'm happy to answer any questions
or give any guidance I can.
-Peff
Re: splitting off shell test framework
On 23 August 2017 at 16:47, Jeff King wrote: > On Wed, Aug 23, 2017 at 02:46:30PM +0100, Adam Spiers wrote: >> >> Done at least once already: >> >> >> >> http://comments.gmane.org/gmane.comp.version-control.git/201591 >> [...] >> >> but sadly since then gmane has shuffled off its mortal coil and I can't >> remember / find what this URL referred to. Please could someone >> point me at a working link? > > Try: > > https://public-inbox.org/git/?q=gmane:201591 > > Public-inbox uses message-ids as its primary key, but keeps a static > mapping of gmane articles to message-ids. But the corpus of gmane ids > isn't growing anymore, and public-inbox URLs can be trivially converted > to other systems which index on the message id[1]. Thanks a lot; that's super helpful! > [1] I actually keep a local archive and convert public-inbox URLs into > local requests that I view in mutt. Sounds like a neat trick - any scripts / config worth sharing?
Re: splitting off shell test framework
On Wed, Aug 23, 2017 at 02:46:30PM +0100, Adam Spiers wrote: > >> Done at least once already: > >> > >> http://comments.gmane.org/gmane.comp.version-control.git/201591 > [...] > > but sadly since then gmane has shuffled off its mortal coil and I can't > remember / find what this URL referred to. Please could someone > point me at a working link? Try: https://public-inbox.org/git/?q=gmane:201591 Public-inbox uses message-ids as its primary key, but keeps a static mapping of gmane articles to message-ids. But the corpus of gmane ids isn't growing anymore, and public-inbox URLs can be trivially converted to other systems which index on the message id[1]. -Peff [1] I actually keep a local archive and convert public-inbox URLs into local requests that I view in mutt.
Re: splitting off shell test framework
I got a helpful response to the following question almost 5 years ago: On 12 November 2012 at 23:09, Adam Spiers wrote: > On Mon, Nov 12, 2012 at 6:18 PM, Drew Northup wrote: >> On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers wrote: >>> As it turned out to be fairly easy, I was wondering if there would be >>> any interest in doing this more formally, i.e. splitting off the >>> framework so that it could be used and improved outside the scope of >>> git development? Of course this would pose the question how git would >>> consume this new project without any risk of destabilisation. I'm >>> guessing that simply using a git submodule would solve the problem, >>> but ICBW ... >>> >>> Just an idea. Interesting, or terrible? :) >> >> Done at least once already: >> >> http://comments.gmane.org/gmane.comp.version-control.git/201591 > > Nice! So hopefully someone will submit patches to build a two-way bridge > via git subtree. Having them diverge would be sad. but sadly since then gmane has shuffled off its mortal coil and I can't remember / find what this URL referred to. Please could someone point me at a working link? Many thanks! Adam
Re: splitting off shell test framework
On Mon, Nov 12, 2012 at 6:18 PM, Drew Northup wrote: > On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers wrote: >> As it turned out to be fairly easy, I was wondering if there would be >> any interest in doing this more formally, i.e. splitting off the >> framework so that it could be used and improved outside the scope of >> git development? Of course this would pose the question how git would >> consume this new project without any risk of destabilisation. I'm >> guessing that simply using a git submodule would solve the problem, >> but ICBW ... >> >> Just an idea. Interesting, or terrible? :) > > Done at least once already: > > http://comments.gmane.org/gmane.comp.version-control.git/201591 Nice! So hopefully someone will submit patches to build a two-way bridge via git subtree. Having them diverge would be sad. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: splitting off shell test framework
On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers wrote: > Hi all, > > I've been pretty impressed with git's test framework, and I'm not > aware of many other (decent) shell-based test frameworks out there. > (One that springs to mind is the one used by rvm, but last time I > looked - admittedly a while ago now - it had limitations). > > Recently a situation arose where I craved the ability to test > something via shell. I did a quick proof of concept and successfully > extracted out the non-git-specific bits of git's test framework to be > used to test something entirely unrelated to git: > > https://github.com/aspiers/shell-env/tree/master/t > > As it turned out to be fairly easy, I was wondering if there would be > any interest in doing this more formally, i.e. splitting off the > framework so that it could be used and improved outside the scope of > git development? Of course this would pose the question how git would > consume this new project without any risk of destabilisation. I'm > guessing that simply using a git submodule would solve the problem, > but ICBW ... > > Just an idea. Interesting, or terrible? :) Done at least once already: http://comments.gmane.org/gmane.comp.version-control.git/201591 -- -Drew Northup -- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: splitting off shell test framework
> -Original Message- > From: Felipe Contreras > Sent: Monday, November 12, 2012 11:44 AM > > On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers > wrote: > > > I've been pretty impressed with git's test framework, and I'm not > > aware of many other (decent) shell-based test frameworks out there. > > (One that springs to mind is the one used by rvm, but last time I > > looked - admittedly a while ago now - it had limitations). > > > > Recently a situation arose where I craved the ability to test > > something via shell. I did a quick proof of concept and successfully > > extracted out the non-git-specific bits of git's test framework to be > > used to test something entirely unrelated to git: > > > > https://github.com/aspiers/shell-env/tree/master/t > > > > As it turned out to be fairly easy, I was wondering if there would be > > any interest in doing this more formally, i.e. splitting off the > > framework so that it could be used and improved outside the scope of > > git development? Of course this would pose the question how git > would > > consume this new project without any risk of destabilisation. I'm > > guessing that simply using a git submodule would solve the problem, > > but ICBW ... > > FWIW, the notmuch project seems to be doing the same; extracting and > using git's test framework. The Apache Maven project is migrating to GIT right now and they just covered a long discussion on the pros and cons of this (sort of). It might be a bit of a read [1] but I can also provide some perspective. The question is asked in reverse in [2] since Maven had them separate and some suggested to merge them. 1: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3ca5d13406-474a-43e6-9708-d5d4de9be...@tesla.io%3e 2: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3c1349937687.79626.yahoomail...@web28903.mail.ir2.yahoo.com%3e smime.p7s Description: S/MIME cryptographic signature
Re: splitting off shell test framework
On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers wrote: > I've been pretty impressed with git's test framework, and I'm not > aware of many other (decent) shell-based test frameworks out there. > (One that springs to mind is the one used by rvm, but last time I > looked - admittedly a while ago now - it had limitations). > > Recently a situation arose where I craved the ability to test > something via shell. I did a quick proof of concept and successfully > extracted out the non-git-specific bits of git's test framework to be > used to test something entirely unrelated to git: > > https://github.com/aspiers/shell-env/tree/master/t > > As it turned out to be fairly easy, I was wondering if there would be > any interest in doing this more formally, i.e. splitting off the > framework so that it could be used and improved outside the scope of > git development? Of course this would pose the question how git would > consume this new project without any risk of destabilisation. I'm > guessing that simply using a git submodule would solve the problem, > but ICBW ... FWIW, the notmuch project seems to be doing the same; extracting and using git's test framework. > Just an idea. Interesting, or terrible? :) That I don't know :) -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
