Re: Death To Sub-Sub-Sub-Directories!
Zapotec wrote:
On 09/05/2011 1:15 PM, Michael Wojcik wrote:
Zapotec wrote:
1. Typing long directory names or click-click-clicking to deeply-nested
folders is a pain, and will be required if you aren't using an IDE
like NetBeans or Eclipse
I often use vim to edit my Java sources, and I don't have to type long
directory names or click-click-click, thanks to the magic of filename
completion.
Completion again. People talk about it like it's a magic bullet, but
it's not, especially when there are a lot of possible completions, which
happens when there is a common prefix (like
src/java/com/mylongcompanyname/mylongprojectname/dal) to a lot of the
filenames.
Works fine for me. Is it possible that your experience is different
from mine? Nah. Surely you must be correct that I experience pain due
to long directory names.
Not that typing long directory names would be any great burden, since
entering a filename is a tiny portion of the work I do when producing
new code or maintaining old.
Every little bit adds up, and time spent doing peripheral tasks is time
not spent coding, testing, or debugging.
You have not demonstrated that it adds up to anything significant.
I'll wager it doesn't. Certainly it's far less than the time I've
spent over the last two decades writing Usenet posts.
2. On Windows, at least, it's not implausible to reach the path name
length limit of the filesystem and run into even more headaches.
Really? The NTFS path name length limit is 32KB, for applications that
use the proper APIs, which seems like it ought to be enough.
And what "proper APIs" might those be, that for instance Microsoft's own
cmd.exe and Explorer evidently don't use?
RTFM. They're the Unicode versions of the File APIs.
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
Gosh, that was hard to find. First hit for "path length" on MSDN.
cmd.exe doesn't support them properly (it does for some builtins, but
it has its own path length limitations that are separate from the OS
ones), because Microsoft frankly doesn't give a damn about cmd.exe.
(If you're going to use one of their shells, they'd like it to be
Powershell.) But that's rather beside the point, which is that the
short path length limitation was corrected in Windows long ago - I
think with NT 4.0.
I might add that Java doesn't use these phantom APIs either, as
evidenced if you try to use java.io.File/FileInputStream to read a file
that exceeds a much shorter length.
Did you specify it correctly, using a UNC name? I thought not.
(Make a directory with a one-letter
name in a drive root and a file with a name about 150 characters long in
it. Then rename the directory to a similarly long name and try to access
it with java.io ... boom! FileNotFoundException.)
-----
C:\tmp>dir
c:\tmp\longdir1234567890123456789012345678901234567890123456789012345
67890123456789012345678901234567890123456789012345678901234567890123456789012345
678901234567890\averylongfilename12345678901234567890123456789012345678901234567
89012345678901234567890123456789012345678901234567890123456789012345678901234567
8901234567890123456789012345678901234567890
The filename or extension is too long.
C:\tmp>java -cp . test
\\?\c:\tmp\longdir123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789
0123456789012345678901234567890\averylongfilename1234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890
foo
-----
Works just fine for me.
Here's the source:
-----
import java.io.*;
class test {
public static void main(String[] args) throws java.io.IOException {
File file = new File(args[0]);
FileInputStream fs = new FileInputStream(file);
int ch;
while ((ch = fs.read()) != -1) {
System.out.print((char)ch);
}
fs.close();
}
}
-----
Even apps
that use the old API get a path length of 260 ASCII characters, which
requires some effort to exceed.
Not with Java's long/and/deeply/nested/package/hierarchies...
I've never had that problem.
If the problem is your Windows source directories are buried under
some unreasonably long path (which probably also contains spacey names
and other infelicities), just create a junction to it in some more
convenient place.
Junctions are those funny-behaving versions of My Documents and such
that are in Vista and Windows 7, right?
Junctions are a facility of NTFS, built on top of reparse points. If
you're going to complain about Windows, maybe you should learn how it
works first.
The last time I checked, the
user can't create those,
Check again.
at least not with the default set of tools
available by e.g. right-click-and-drag in Explorer.
Whereas in Unix and Linux installations, all possible actions are
available in the various GUI file managers?
If Microsoft had been intelligent, competent, and capable of even decent
copycatting, let alone true creativity, outside of the
inventing-new-anticompetitive-dirty-tricks department,
And now the ad hominem. Let's all watch as Zapotec loses the ability
to formulate an actual argument.
Vista would have
included real proper symlinks,
It does:
-----
C:\tmp>mklink /?
Creates a symbolic link.
MKLINK [[/D] | [/H] | [/J]] Link Target
/D Creates a directory symbolic link. Default is a file
symbolic link.
/H Creates a hard link instead of a symbolic link.
/J Creates a Directory Junction.
Link specifies the new symbolic link name.
Target specifies the path (relative or absolute) that the new
link
refers to.
-----
NTFS also supports hard links and junctions.
which you can click through in Explorer
As indeed you can.
without getting error messages, and which would have been available on
the right click menu: right click, drag, "Make symlink here". :P
I agree that being able to make links and junctions from Explorer
would be useful for lazy whiners who can't be bothered to learn how
their OS works.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University