> >Just as a basic sanity check, you should also be able to put the cursor
> >on the line corresponding to a file to open in a directory buffer and
> >do Alt X, dirOpenFile, to open that file by hand (so to speak). (If Alt
> >X doesn't work, try "Execute Command..." on the File menu.)
> "Alt X" works fine. After entering "dirOpenFile" (and a subsequent
> [ENTER] nothing happens.
> >You should also be able to go into a directory buffer and use
> >describeKey (it's on the Help menu and mapped by default to Alt K), and
> >then hit Enter (or Ctrl Shift G) and see that the keystroke in question
> >is mapped to dirOpenFile.
> I've checked that "Enter" and "Ctrl Shift G" are mapped to "dirOpenFile"
> I've tested the following features, too: If I try to copy/move via
> directory buffer a file I get the
> following dialog: "Copy/Move 0 tagged files to:". I may type in another
> file name, nothing
> happens. I am not able to delete a file via directory buffer, too.
All of this suggests that the keyboard has nothing to do with the
J uses the output of "ls -l" to create the directory buffer, and then
uses a regular expression to find the filename at the end of each line.
I suspect that on your system, for some reason, "ls -l" is generating
output in an unusual format, and j is unable to parse it.
You might try adding this line to ~/.j/prefs:
dirUseNativeFormat = false
This will force j to use its own internal format for directory buffers
instead of invoking "ls -l" (this is what happens on Windows by
You should then see directory listings in a different format (like the
format on Windows), and maybe Enter (or Alt X, dirOpenFile) will work.
If it does, the next question is, why is "ls -l" using a strange
format, and how can we work around that problem? If you send me the
exact contents of a directory buffer (do File/New, then copy and paste
the whole directory buffer into the new buffer and save it as text),
I'll be glad to take a look at it.
> On the other side I get the following messaging on the terminal/shell I
> startet j:
> WARNING: Could not lock System prefs.Unix error code 1217297544.
> 14.11.2002 23:36:19 java.util.prefs.FileSystemPreferences syncWorld
> WARNING: Couldn't flush system prefs:
> java.util.prefs.BackingStoreException: Couldn't get file lock.
> 14.11.2002 23:36:49 java.util.prefs.FileSystemPreferences
> Does it make any sense to you.
Is your home directory on an NFS mount?
There is a bug in certain versions of Java that relates to the
preferences stuff introduced in Java 1.4 (which j doesn't use at all),
in the case where your home directory is on an NFS mount.
But I thought the bug was fixed in 1.4.1, so I'm not sure what the
You might try the Blackdown 1.4.1 beta, which seems to be a bit
friendlier to Linux in some ways:
Or, if you're using Sun 1.4.1 fcs, you might try Sun 1.4.1_01.
In any case, I don't think this problem has anything to do with j, and
it's probably harmless if all it does is produce those error messages.
Thanks for your help!