Apparently, under Linux the etrace path is interpreted
relative to the e.home directory. here is the error
message:
[root@localhost elang]# ../startCapDesk
=== 2002-02-06T23:28:51.529Z
(TraceLogDescriptor.setDir:TraceLogDescriptor.java:301) WRN
trace: The log directory was set to
'/root/elang/"/root/capData/etrace"', which is not
currently a directory.
=== 2002-02-06T23:28:51.634Z
(TraceLogDescriptor.startUsing:TraceLogDescriptor.java:395)
ERR
trace: Could not open new trace file
'/root/elang/"/root/capData/etrace"/etrace.2002-02-06T23_28_51.421Z.txt'.
and here is the passage from eprops.txt
# Where is E installed? If this file is eprops.txt (as
opposed to
# eprops-template.txt) then this eprops.txt file should
be in this
# directory.
#
# For example, "c:/Program Files/erights.org/"
e.home="~/elang/"
# What is the absolute path of the Java executable
command? This must
# be a Java compatible with Sun's JDK >= 1.3. On
MSWindows, if you
# wish to suppress the MSDOS console window, use a
javaw.exe command
# rather than a java.exe command.
#
# For example, "d:/jdk1.3/bin/java.exe"
e.javacmd="/usr/bin/java"
# When E shortcuts are launched from the desktop, where
should their
# current directory be? Under *nix currently, this
option does
# nothing. On MSWindows, this option affects only newly
generated
# shortcuts. After changing this option, rerun the setup.e
# command to generate new shortcuts.
#
# For example: "c:/WINDOWS/Desktop" or "".
e.launch.dir="~/Desktop"
# Where does trace data go? This directory will accumulate
# debugging information provided by running E programs
in order to
# facilitate a post-mortem analysis of problems. The
trace system
# treats the directory as a large circular buffer
giving a finite
# window into the past in exchange for a finite memory
burden.
#
# For example: "c:/WINDOWS/temp/etrace" or "".
TraceLog_dir="/root/capData/etrace"
