Re: [Wireshark-dev] Controlling the location of plugins directory
Jeff Morriss wrote: Bob Doolittle wrote: Hi, Can wireshark handle env-variable control of the location of the plugins directory (similar to LD_LIBRARY_PATH etc)? I haven't found it, and desperately need it. I work in an environment where I commonly use several platforms, including Solaris sparc and x86 as well as various Linux distros. So I need to build architecture-dependent versions of a plugin, and currently can't find a way to deploy this in an easy fashion in the $HOME directory. Take a look at bug 1476: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1476 It looks like what you want may be (partially) implemented already. Very cool, thanks! This would indeed solve my issue. However, I'm not a bugzilla jock. It looks to me like somebody has submitted a patch, but it hasn't been integrated into the main source yet (Status=NEW). Is that correct? I could always build my own, but that sort of defeats the purpose (i.e. I wouldn't need the plugin in my home directory - I could just put it into my built copies of wireshark). What about preferences, do they get stored in $WIRESHARK_HOME as well? That would be unfortunate - it would be undesirable to maintain multiple copies... -Bob ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Controlling the location of plugins directory
Richard van der Hoff wrote: Bob Doolittle wrote: What about preferences, do they get stored in $WIRESHARK_HOME as well? That would be unfortunate - it would be undesirable to maintain multiple copies... Yes. You could symlink all the versions together though? Yes, I suppose :) It would be good to know if -P persconf solves your usecase. Yes, I think so, assuming that it controls where plugins are found as well as the preferences. Wouldn't it have been cleaner to use two options, instead of one option plus a string qualifier (i.e. persconf: vs persdata:)? I could always build my own, but that sort of defeats the purpose (i.e. I wouldn't need the plugin in my home directory - I could just put it into my built copies of wireshark). Hrm; well, we don't do binary builds except for win32 and afaik we don't have any immediate plans for a release, so it's going to be a while before your favourite distro picks up any changes we make - so you're probably going to be stuck with building your own for a while, anyway... In my case, I work in an enterprise where we have a shared app server, and just want to pick up the built version on the app server instead of building my own (particularly since I will be circulating the plugin to a number of folks, and would rather not circulate a bunch of copies of wireshark for multiple platforms as well). I could perhaps convince the maintainers of the app server to build a new version as long as it's from the main branch and the branch builds a stable app. Are your -P changes in the main repository branch now? -Bob ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Controlling the location of plugins directory
Bob Doolittle wrote: It would be good to know if -P persconf solves your usecase. Yes, I think so, assuming that it controls where plugins are found as well as the preferences. Wouldn't it have been cleaner to use two options, instead of one option plus a string qualifier (i.e. persconf: vs persdata:)? I'll have to defer to Ulf on that. There was no doubt some reasoning behind it. I could perhaps convince the maintainers of the app server to build a new version as long as it's from the main branch and the branch builds a stable app. Are your -P changes in the main repository branch now? They aren't my changes... but yes, they are. Cheers, Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Controlling the location of plugins directory
Yes, I think so, assuming that it controls where plugins are found as well as the preferences. Wouldn't it have been cleaner to use two options, instead of one option plus a string qualifier (i.e. persconf: vs persdata:)? I'll have to defer to Ulf on that. There was no doubt some reasoning behind it. Hi! Given the fact that we already have a lot of options and we might need some more -P suboptions in the future (e.g. temp, plugin, ...), I was simply assuming that in the long run we're running out of letters. There might be other options in the future also in a need for a letter. So having a suboption under -P seemed a good idea to me. As -a and -b already working similiar, I didn't even invented a new mechanism for it. BTW: I don't see any reason to call it clean or unclean anyway ... Regards, ULFL ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Controlling the location of plugins directory
Hi, Can wireshark handle env-variable control of the location of the plugins directory (similar to LD_LIBRARY_PATH etc)? I haven't found it, and desperately need it. I work in an environment where I commonly use several platforms, including Solaris sparc and x86 as well as various Linux distros. So I need to build architecture-dependent versions of a plugin, and currently can't find a way to deploy this in an easy fashion in the $HOME directory. I've arranged my shell rc files so that I set my executable $PATH to include a platform-dependent $HOME/bin type of directory during login[1]. It would be reasonable to do something similar for some variable that specified my wireshark plugin directory for the current platform. Thanks, Bob [1] Specifically, it adds $HOME/bin/$(uname -s).$(uname -p), e.g. $HOME/bin/SunOS.sparc or $HOME/bin/Linux.i386 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
