Reputation: 15010
I have the following bashscript in my /opt/mydev
folder
COMMAND=""
buildCommand2() {
COMMAND=$COMMAND"--tab -e 'bash -c \"source ~/.bashrc; source ~/Desktop/developer/setup.bash; cd /opt/mydev/$1& $1/$1; bash\"' "
}
buildCommand2 'MyFileManager'
Now /opt/mydev
folder contains a folder named MyFileManager
which contains an executeable named MyFileManager
When I run the above bash script, it starts up MyFileManager
in a new tab.
I now want to run the executeable MyFileManager
with valgrind
valgrind --leak-check=full \
--show-leak-kinds=all \
--track-origins=yes \
--verbose \
--log-file=valgrind-out.txt \
./MyFileManager/MyFileManager
How do I do this? I found the buildCommand2
quite cryptic
Upvotes: 0
Views: 121
Reputation: 31374
i typically use an additional (empty by default) variable, that injects valgrind
(or gdb
; or wine
; or...) in the right place....
for whatever reasons i call it INTERPRETER
, but pick your own better name...
COMMAND=""
: ${INTERPRETER:=""}
buildCommand2() {
COMMAND=$COMMAND"--tab -e 'bash -c \"source ~/.bashrc; source ~/Desktop/developer/setup.bash; cd /opt/mydev/$1 & ${INTERPRETER} $1/$1; bash\"' "
}
buildCommand2 'MyFileManager'
than run your script with:
$ export INTERPRETER="valgrind --leak-check=full \
--show-leak-kinds=all \
--track-origins=yes \
--verbose \
--log-file=valgrind-out.txt"
$ mybuildcommand
or in one line:
$ INTERPRETER="gdb --args" mybuildcommand
notes:
: ${INTERPRETER:=""}
is effectively a no-op; it only serves to document the existence of the variable. you could use it to provide a default interpretervalgrind
(or whatver) on the cmdline; this is by design (as I usually want different variants to be readily available)Upvotes: 2