From: Peter G. <pe...@ar...> - 2002-11-15 05:49:34
|
> >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 problem. 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 default). 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 > checkLockFile0ErrorCode > > 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 problem is. You might try the Blackdown 1.4.1 beta, which seems to be a bit friendlier to Linux in some ways: http://www.blackdown.org 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! -Peter |