9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Rubén Berenguel" <ruben@mostlymaths.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] Odd behaviour of "plumb" in plan9ports: Stripped line numbers
Date: Sat, 20 Apr 2013 18:26:16 +0200	[thread overview]
Message-ID: <CAHk2O6p_tARPtp9CRKJ_N=5HvnuGiv8UWR18UCnV1o4-7v6uDA@mail.gmail.com> (raw)

Hi everyone,

yesterday, out of boredom and geekness I decided to add a plumbing
rule to my plumber, to allow me to search in subdirectories with The
Silver Searcher (the command line ag, best described here:
https://github.com/ggreer/the_silver_searcher) In short, ag "something
to search" [where] will search, and it's quite fast for source code
(faster than grep, and supposedly faster than ack). My idea was simply
adding a plumbing rule that allows me to search the current directory
by right clicking in acme an expression like ag:word or ag:"longer
thing". Pretty useful, I think, even more since ag spits data in the
standard filename:lineno format.

First problem, the plumber doesn't usually know where it is. I.e. if I
start the plumber in directory /somewhere, all subsequent searches
come straight from /somewhere (ag defaults to "current execution
directory", this could be overriden by an extra parameter, but makes
using it inside acme feel unnatural) I solved this in a very naive
way, by adding to my plumbing rule:

arg isdir .

This sets the variable $dir to the current directory (according to plumb(7)).

Now we get to the real meat of the problem. In short, plumb is eating
line numbers. What do I mean? First, here is the plumbing rule:

type is text
data matches 'ag:"?([a-zA-Z¡-�0-9_\-./]+)"?'
arg isdir .
plumb start bash -c 'nag '$1' '$dir

I created a small shell script named "nag" to test where the error
was, I wasn't sure of the source (and editing a script is more time
effective than rewriting a plumbing rule you have to reload)

The script currently does:

#/bin/bash
ag  "$1" $2 --nogroup --nocolor > test

basically so I can test it, since it does not work as expected. If I
run plumb ag:acme from within the root of the plan9ports tree (my
shell is zsh, by the way), head test looks like:

/usr/local/plan9/plan9port/acid/acme:// support for acme; acid must be
run with /acme/acid/$cputype/Acid
/usr/local/plan9/plan9port/acid/acme: printto("/tmp/acme.acid", eval code);
/usr/local/plan9/plan9port/acid/acme: rc("cat /tmp/acme.acid | wnew -d
"+"Acid/-stk'("+itoa(pid)+")'");
/usr/local/plan9/plan9port/acid/acme: printto("/tmp/acme.acid", stk());
/usr/local/plan9/plan9port/acid/acme: rc("cat /tmp/acme.acid | wnew -d
"+"Acid/-'"+name+"("+itoa(pid)+")'");
/usr/local/plan9/plan9port/acid/acme: printto("/tmp/acme.acid", threadstk(tid));
/usr/local/plan9/plan9port/acid/acme: rc("cat /tmp/acme.acid | wnew -d
"+"Acid/-"+name+"'("+itoa(pid)+")'");
/usr/local/plan9/plan9port/bin/": 9p read acme/$winid/body
/usr/local/plan9/plan9port/bin/adict:. $PLAN9/lib/acme.rc
/usr/local/plan9/plan9port/bin/Getdir:# Click on an acme directory
window and then execute Getdir

If instead I run nag "acme" . --nogroup --nocolor > test, head test looks like:

./acid/acme:1:// support for acme; acid must be run with
/acme/acid/$cputype/Acid
./acid/acme:8: printto("/tmp/acme.acid", eval code);
./acid/acme:9: rc("cat /tmp/acme.acid | wnew -d "+"Acid/-stk'("+itoa(pid)+")'");
./acid/acme:16: printto("/tmp/acme.acid", stk());
./acid/acme:17: rc("cat /tmp/acme.acid | wnew -d
"+"Acid/-'"+name+"("+itoa(pid)+")'");
./acid/acme:24: printto("/tmp/acme.acid", threadstk(tid));
./acid/acme:25: rc("cat /tmp/acme.acid | wnew -d
"+"Acid/-"+name+"'("+itoa(pid)+")'");
./bin/":7: 9p read acme/$winid/body
./bin/adict:4:. $PLAN9/lib/acme.rc
./bin/Getdir:3:# Click on an acme directory window and then execute Getdir

As you can see, output is clearly different. For one, . is being
rewritten as the complete base dir. This is to be expected, since $dir
is expanded to current dir, not . and ag plays short and uses just .
The problem is that line number is being stripped, and I can't figure
where or why, or how to fix it (running nag "acme" fulldir gives the
same output, with line numbers, so it's not a longlines problem).
Without line numbers there's no (interesting) point in searching stuff
from within acme.

If I run ag from within Win in acme (previously setting
SHELL=$PLAN9/bin/rc) the results are correct, even running from within
rc the full command bash -c 'ag "acme" . --nogroup --nocolor' gives
the expected results.

I'm completely puzzled about *where* the line numbers are being
stripped, and even more, *why*. I have taken a look at the source for
plumb and the plumber, but I can't find where the code to execute a
start/client command is located.

Any ideas?

Regards,

Ruben



             reply	other threads:[~2013-04-20 16:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-20 16:26 Rubén Berenguel [this message]
2013-04-20 16:52 Rubén Berenguel

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='CAHk2O6p_tARPtp9CRKJ_N=5HvnuGiv8UWR18UCnV1o4-7v6uDA@mail.gmail.com' \
    --to=ruben@mostlymaths.net \
    --cc=9fans@9fans.net \
    /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 NNTP newsgroup(s).