Ethereal-dev: [Ethereal-dev] Re: [Ethereal-users] Product performs differently than documentat

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 16 Jan 2004 15:00:11 -0800

On Jan 10, 2004, at 4:02 AM, Richard Urwin wrote:

The capture file window I'm pulling up looks different (see attachment)
and is not referencing libpcap files but only MIB files.

The startup directory tends to default to that in Windows.

The startup directory defaults to the current directory of the Ethereal process.

Windows shortcuts have a "working directory" property; when a shortcut for a program is double-clicked, the process started for that program starts out with the directory specified by that property as its current directory.

When NSIS (the tool used for the Ethereal installer) creates a shortcut, it uses the current output directory as the working directory; the current output directory is set in NSIS scripts by the SetOutPath command, and the last SetOutPath command in the Ethereal NSIS script before creating the shortcuts sets it to the MIB directory (as the MIBs are the last files installed).

That's probably not the appropriate directory to start out in.

There are no capture files installed with ethereal, so there is no capture files directory to start in, until you have created one. There are sample
captures on the website if you want some.

Additionally, I
am unable to create directories. I either get an error stating that "The path to the [file path] does not exist" (This is after I have created it
and it is viewable in windows), or I am usually told I don't have
permission to create the directory if I try typing in the path manually
(I am logged in as Admin).

I don't know why that would be. Ethereal does not pay special attention to "My
Documents" or "Desktop" like native Windows applications.

Well, perhaps it should - even on UNIX.

I'm not sure what the right starting directory would be on various desktop environments.

One possibility would be the user's "top-level directory", which would be their home directory on UNIX and their profile directory on Windows (I don't call it the "home directory" as that has another meaning on Windows, probably dating back to the LAN Manager days).

Another possibility would be the user's "documents" directory, e.g. top-level directory\My Documents on Windows, top-level directory/Documents on Mac OS X, top-level directory itself (I think) on KDE, etc.. I'm not sure whether capture files would be considered "documents" in that sense, however.

A third possibility would be a "captures" directory under the top-level directory; on Windows it should probably be top-level directory\Captures, but on UNIX we might want to make it top-level directory/captures instead, so you don't have to capitalize it (that might not be an annoyance on Mac OS X with your home directory on a case-insensitive file system such as HFS+, but it might be a nuisance on other UNIXes and even on Mac OS X with your home directory on a case-sensitive NFS server, as mine is at work, or on a case-sensitive file system such as UFS or case-sensitive HFS+). For that to work right, we might have to construct that directory as part of the installation process, which might be a pain on various UNIXes.

If Ethereal is launched from the desktop, we could make that happen, at least on UNIX, without code changes - I think we could arrange to set the output directory in the NSIS script before making the shortcuts:

	"SetOutPath $PROFILE" for the top-level directory;

"SetOutPath $DOCUMENTS", preceded by "SetShellVarContext current" and followed by "SetShellVarContext all", for the user's "documents" directory

"SetOutPath $PROFILE\Captures" for a "Captures" directory (there might be some way to internationalize "Captures", although we'd then have to localize it...).

For UNIX desktops that implement the desktop entry spec:

http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry- spec-0.9.4.html

there's a "Path" key that appears to be the equivalent of the "working directory" property for Windows desktop shortcuts; we'd have to tweak installers to set that to the appropriate path, however. I think that, by default, anything launched from the KDE desktop would be run from the user's home directory, i.e. their top-level directory; the same might be true with other UNIX+X desktops.

In Mac OS X, an alias on the desktop, when double-clicked, appears to launch the application in the top-level directory/Desktop directory, i.e. the current directory is the desktop. It might be possible to put X11 applications such as Ethereal into an application bundle; I don't know in what directory it'd be launched if we did that.