From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20988 invoked by alias); 24 Nov 2009 17:15:21 -0000 Received: (qmail 20651 invoked by uid 48); 24 Nov 2009 17:14:56 -0000 Date: Tue, 24 Nov 2009 17:15:00 -0000 Message-ID: <20091124171456.20650.qmail@sourceware.org> From: "foom at fuhm dot net" To: systemtap@sources.redhat.com In-Reply-To: <20091108020716.10917.foom@fuhm.net> References: <20091108020716.10917.foom@fuhm.net> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/10917] environment variable expansion in executable search X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00669.txt.bz2 ------- 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.