Re: r45615: Read the program name rather than hardcoding it

[Guy Harris <guy () alum mit edu>]

On Oct 18, 2012, at 4:18 AM, Anders Broman <anders.broman () ericsson com> wrote:

> I changed most occurrences in the nsi installer of wireshark to ${PROGRAM_NAME} and also in some places of 
> Makefile.nmake in error as it now seems. So at least as convention (on windows) we used wireshark/Wireshark 
> (As file names are case insensitive on Windows I don't think capital W or not matters).
> For:
> - Part of the program installation path (InstallDir $PROGRAMFILES\Wireshark)
> - Name of the wireshark executable (wireshark.exe)
> - part of the path name to personal configuration files (%APPDATA%/Wireshark)
>
> So should I drop this completely and back out the changes done so far?

I think the high-order bit is that, if you're going to make the file name of the personal configuration directory 
configurable, the code must *not* determine the file name by looking at the last component of the path name of the 
executable - that means that Wireshark and TShark would have different personal configuration directories in the 
*standard* Wireshark package, which is a radical change and is probably an undesirable change.

I think it would also be highly desirable that, if you run Wireshark from the build directory, it be able to find the 
personal configuration files appropriate to that version of Wireshark.

Given that, I think it would be best if the personal configuration directory name be configurable at *compile time*, 
i.e. be set with a #define in, for example, config.nmake.

I suspect that whoever's building the version of Wireshark knows whether it would require a separate set of 
configuration files or not, so I think that the personal configuration directory name should just default to 
"Wireshark" on Windows, regardless of the name of the directory under $PROGRAMFILES into which it's installed or the 
name given to any of the executable images, and have the configuration #define in config.nmake be independent of the 
name of the directory under $PROGRAMFILES into which it's installed or, *if* that's configurable, the name of the 
Wireshark executable image.  That would allow somebody to build a special version of Wireshark that *can* use the same 
personal configuration directory as the standard version.

That also would allow special versions of Wireshark, using a separate personal configuration directory, to be built for 
UN*X, regardless of where the special version is installed - under /Applications/Wireshark-special.app, under 
/opt/wireshark-special, in /usr/local/bin/$program-special, etc..

How the executable image should be named may depend on the platform's conventions.

For Windows, I don't know whether there would be problems if you have $PROGRAMFILES\Wireshark-special\wireshark.exe 
rather than $PROGRAMFILES\Wireshark-special\wireshark-special.exe.  If you have both $PROGRAMFILES\Wireshark-special 
and $PROGRAMFILES\Wireshark, there are a couple of ways of getting at the right version of the command-line tools - 
either set your search path to include the right directory, or name the command-line tools differently, so that you 
have $PROGRAMFILES\Wireshark-special\tshark-special.exe and $PROGRAMFILES\Wireshark\tshark.exe, and you can run 
"tshark-special" or "tshark".  If the name of the dumpcap executable changes, Wireshark and TShark need to know about 
that when built.

For OS X app bundles, the actual application binary is hidden from the user, so its name doesn't matter.  The installer 
puts scripts in /usr/local/bin that run the actual command-line executables, which are in the application bundle.  In 
that case, having "tshark-special" and "tshark" would probably work better, as the user's more likely to run the 
command-line tools from /usr/local/bin rather than to tweak $PATH to search in 
/Applications/Wireshark{-special}.app/Contents/Resources/bin.

For installation under /opt, I'm not sure whether users would expect /opt/wireshark-special/bin/wireshark or 
/opt/wireshark-special/bin/wireshark-special.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe