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