[Bug translator/10917] New: environment variable expansion in executable search

[Bug translator/10917] New: environment variable expansion in executable search

[foom at fuhm dot net]

I'd like to be able to do:
probe process("$INSTALL/lib/libMyStuff.so").function("hello") {}

That is: in addition to doing $PATH finding for the process probe, I'd like it to first expand environment 
variables from the user (the one running stap)'s environment.

At first thought, I'd have $$ to escape a $, and also support "${ENVVARNAME}".

If you think this is a good idea, I should be able to come up with a patch to implement it.

-- 
           Summary: environment variable expansion in executable search
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: foom at fuhm dot net


http://sourceware.org/bugzilla/show_bug.cgi?id=10917

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10917] environment variable expansion in executable search

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-11-09 16:42 -------
Can you look at bug #10485, and see if that would be another way of solving your
problem?  The gist would be to install your tapset script under a subdirectory
name that encodes your $INSTALL directory.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10917

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10917] environment variable expansion in executable search

[foom at fuhm dot net]

------- Additional Comments From foom at fuhm dot net  2009-11-09 17:33 -------
I don't think that would work for me. I want this for development-use, so installing stuff into system 
directories is not really appropriate. The install directory for the source tree I'm working on (and I may be 
working on multiple) is selected via the env var $APPINSTALL (and $PATH is updated automatically as well 
via a shell function).

So, if I check in a stp script to the source tree, I want it to find the libs for my *current* install, which is 
determined by $APPINSTALL. I don't want to have to install the stp script into a special system location in 
order for it to work -- I should be able to edit and use it directly from the source tree, ideally.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10917

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10917] environment variable expansion in executable search

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-11-24 16:44 -------
James, in the PR10485 model, one would do this by installing a
tapset file such as
     probe mystuff.hello = process("libMyStuff.so").function("hello") {}
into
     /ANYWHERE/tapset/AUTOPATH/$INSTALL/lib/libMyStuff.so
then
     stap -I /ANYWHERE/tapset -e 'probe mystuff.hello { }'
This may be suitable for probe points that are a priori known interesting.

For ad-hoc probing, there are a few other ways:
1) build the script on the fly:   
   #! /bin/sh
   stap -e 'probe process("'$INSTALL'/lib/libMyStuff.so").function("hello") { ... }'
so a shell does the interpolation.
2) put $INSTALL/lib into your temporary PATH, so that
   stap -e 'probe process("libMyStuff.so").function("hello") { }'
would work since we search $PATH for unqualified process("..") names
3) (wait for systemtap bug #6880, which should automate searching for
shared libraries based on program binaries and $LD_LIBRARY_PATH)
4) (wait for another possible extension:   @env("name")  as a parse-time
expanded literal ... but this would also require parse-time concatenated
string literals in order to be useful as a process probe parameter:
    probe process (@env("INSTALL") "/lib/libMyStuff.so") { |


By the way the reason I'm hesitant about the original proposal
-- interpolation of values within string literals -- is because
this would be the first such scenario in systemtap.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10917

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10917] environment variable expansion in executable search

[foom at fuhm dot net]

------- Additional Comments From foom at fuhm dot net  2009-11-24 17:14 -------
Thanks for the response. 

Bug 6880 indeed looks like a reasonable solution to my problem: if a "library" probe searched 
LD_LIBRARY_PATH for the library, that'd work well for me in this situation, and if process(...).library(...) 
found the library no matter what way that process loaded it, that'd be useful for many other situations.

I also think generic (usable anywhere) parse-time env var expansion suppport would be quite nice too. 
Your proposal #4 is certainly a *much* better idea than my proposal of just doing it in this one special 
case.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10917

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.