9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Odd behaviour of "plumb" in plan9ports: Stripped line numbers
@ 2013-04-20 16:52 Rubén Berenguel
  0 siblings, 0 replies; 2+ messages in thread
From: Rubén Berenguel @ 2013-04-20 16:52 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

D--n!

My fault: I had created a function named ag in rcmain (my first try
involved a function and writing :ag something to test how to call rc
functions from within acme and get this search feature working.) I had
completely forgotten until a few seconds ago: removing it makes it
work as expected. Well, lesson learnt: the error is usually the users
fault :D

Well, if you want to have ag: within your acme, change the nag script to read:

#/bin/bash
ag  "$1" $2 --nogroup --nocolor | plumb -i -d edit -a 'action=showdata
filename='$2'/ag/'$1

This can also be written as just a rule within "plumbing," no need for
an auxiliary shell script but since now it is working I'd rather not
touch it in a while ;)

Regards,

Rubem



^ permalink raw reply	[flat|nested] 2+ messages in thread

* [9fans] Odd behaviour of "plumb" in plan9ports: Stripped line numbers
@ 2013-04-20 16:26 Rubén Berenguel
  0 siblings, 0 replies; 2+ messages in thread
From: Rubén Berenguel @ 2013-04-20 16:26 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-04-20 16:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-20 16:52 [9fans] Odd behaviour of "plumb" in plan9ports: Stripped line numbers Rubén Berenguel
  -- strict thread matches above, loose matches on Subject: below --
2013-04-20 16:26 Rubén Berenguel

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).