Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9845 > unrolled thread

A strange behaviour of a File property

Back to article view | Back to comp.lang.java.programmer

Contents

  A strange behaviour of a File property alelvb@inwind.it - 2011-11-11 05:45 -0800
    Re: A strange behaviour of a File property Lew <lewbloch@gmail.com> - 2011-11-11 07:34 -0800
      Re: A strange behaviour of a File property alelvb@inwind.it - 2011-11-11 09:28 -0800
        Re: A strange behaviour of a File property Lew <lewbloch@gmail.com> - 2011-11-11 14:17 -0800
          Re: A strange behaviour of a File property alelvb@inwind.it (Alexo) - 2011-11-12 15:04 +0100
            Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 09:15 -0500
              Re: A strange behaviour of a File property alelvb@inwind.it (Alexo) - 2011-11-12 16:17 +0100
                Re: A strange behaviour of a File property Zlatko Đurić <zladuric@gmail.com> - 2011-11-12 16:09 +0100
                Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 10:13 -0500
    Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-11 16:25 +0000
      Re: A strange behaviour of a File property alelvb@inwind.it - 2011-11-11 09:42 -0800
        Re: A strange behaviour of a File property Arne Vajhøj <arne@vajhoej.dk> - 2011-11-11 13:24 -0500
      Re: A strange behaviour of a File property Lew <lewbloch@gmail.com> - 2011-11-11 14:13 -0800
      Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-11 20:38 -0500
        Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-12 03:21 +0000
          Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 08:26 -0500
            Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-12 22:09 +0000
              Re: A strange behaviour of a File property Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 17:40 -0500
                Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 01:28 +0000
                  Re: A strange behaviour of a File property Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 20:42 -0500
                    Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 12:15 +0000
                    Re: A strange behaviour of a File property Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-13 12:42 +0000
                      Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 13:06 +0000
          Re: A strange behaviour of a File property Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 17:25 -0500
            Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 01:15 +0000
              Re: A strange behaviour of a File property Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 20:40 -0500
                Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 12:42 +0000
              Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-12 21:11 -0500
                Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-13 20:50 +0000
                  Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-14 08:18 -0500
                    Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-14 17:38 +0000
                      Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-14 21:51 -0500
                        Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-15 14:17 +0000
                          Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-15 22:20 -0500
                            Re: A strange behaviour of a File property Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-16 12:14 +0000
                              Re: A strange behaviour of a File property Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-16 08:10 -0500
        Re: A strange behaviour of a File property Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-11 19:46 -0800
        Re: A strange behaviour of a File property Owen Jacobson <angrybaldguy@gmail.com> - 2011-11-14 00:24 -0500
          Re: A strange behaviour of a File property Lew <lewbloch@gmail.com> - 2011-11-13 22:00 -0800
    Re: A strange behaviour of a File property Roedy Green <see_website@mindprod.com.invalid> - 2011-11-12 05:00 -0800
      Re: A strange behaviour of a File property Arne Vajhøj <arne@vajhoej.dk> - 2011-11-12 09:15 -0500

Page 1 of 3  [1] 2 3  Next page →

#9845 — A strange behaviour of a File property

Hello,
I've written this toy-code to test the funcionality of the File class
and I've found a strange behaviour.
My code works only with the dot directory (the directory where the
Main.class is contained) and it doesn't with any other. What's the
problem?

here is the code

<cut here>

import java.io.*;

public class Main {
	public static void main(String[] args){
		File f = new File(".");        // try to change the path
		File[] file_array = null;
		String[] content = null;
		content = f.list();
		file_array = new File[content.length];
		boolean[] bool_array1 = new boolean[content.length];
		boolean[] bool_array2 = new boolean[content.length];

		for(int i=0; i<content.length; i++){

			file_array[i] = new File("." + "\\" + content[i]);
			bool_array1[i] = file_array[i].isDirectory();
			bool_array2[i] = file_array[i].isFile();

			System.out.println(content[i] + "\tis a directory?: " +
bool_array1[i]);
		}
	}

}

[toc] | [next] | [standalone]

#9848

ale...@inwind.it wrote:
> I've written this toy-code to test the funcionality of the File class
> and I've found a strange behaviour.
> My code works only with the dot directory (the directory where the
> Main.class is contained) and it doesn't with any other. What's the
> problem?

What *precisely* are the symptoms when it doesn't work, and what values other than "." have you tried?

It's difficult to help when you're vague about the problem.

> here is the code
> 
> <cut here>
> 
> import java.io.*;
> 
> public class Main {
> 	public static void main(String[] args){
> 		File f = new File(".");        // try to change the path

DO NOT INDENT USENET POSTS WITH TAB CHARACTERS!

If you're asking the world of strangers to help, please do try to make it easy to read your code.

Use spaces to indent, up to four per level.

> 		File[] file_array = null;'
> 		String[] content = null;
> 		content = f.list();

Why not 'String[] content = f.list();'?

Extra asssignments to 'null' are not helpful.

> 		file_array = new File[content.length];
> 		boolean[] bool_array1 = new boolean[content.length];
> 		boolean[] bool_array2 = new boolean[content.length];
> 
> 		for(int i=0; i<content.length; i++){
> 
> 			file_array[i] = new File("." + "\\" + content[i]);

Does 'content[i]' contain what you expect?

> 			bool_array1[i] = file_array[i].isDirectory();
> 			bool_array2[i] = file_array[i].isFile();

This value is not used?

> 			System.out.println(content[i] + "\tis a directory?: " +
> bool_array1[i]);
> 		}
> 	}
> 
> }

What are your outputs in the scenario that "works" (and what does "works" mean?) and in the scenario that doesn't?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9850

> If you're asking the world of strangers to help, please do try to make it easy to read your code.
>
> Use spaces to indent, up to four per level.

ok it'll be done, i'm sorry


> What are your outputs in the scenario that "works" (and what does "works" mean?) and in the scenario that doesn't?


the call to isDirectory() returns true only for the directories
present in the "." directory, for every other path it returns always
false, even when the file >is< a directory.

[toc] | [prev] | [next] | [standalone]

#9857

On Friday, November 11, 2011 9:28:59 AM UTC-8, ale...@inwind.it wrote:
> > If you're asking the world of strangers to help, please do try to make it easy to read your code.
> >
> > Use spaces to indent, up to four per level.
> 
> ok it'll be done, i'm sorry
> 
> 
> > What are your outputs in the scenario that "works" (and what does "works" mean?) and in the scenario that doesn't?
> 
> 
> the call to isDirectory() returns true only for the directories
> present in the "." directory, for every other path it returns always
> false, even when the file >is< a directory.

I repeat:

What *precisely* are the symptoms when it doesn't work, and what values other than "." have you tried? 

It's difficult to help when you're vague about the problem. 

What is "every other path"?  What are the inputs and outputs that you see?

The code you show doesn't show the scenario that fails.  How can we tell what's failing when you don't show the code?

The word "precisely" was emphasized for a reason.  Your information is so vague, I don't even know what's going wrong much less why.

Follow the advice in 
http://sscce.org/

Try to imagine that you are not at all familiar with your code, and read your explanation.  Does it tell you enough to figure out what's wrong, let alone why?

Where's the code?

Where's the code?

What are the outputs?

You haven't shown any inputs, outputs or code for the failure case.

Sorry, can't help you with such little data.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9875

> Sorry, can't help you with such little data.

the purpose of the program is to list the content of a directory and to
show if a file is a directory using isDirectory().
When I execute the code with the dot "." directory, the output of the code
is:

classpath	is a directory?: false
project	is a directory?: false
settings	is a directory?: true
Main.class	is a directory?: false
Main.java	is a directory?: false

the behaviour of the program is correct and it shows that the file
settings is in reality a directory. When I try to change path utilising
for example "/", the root directory of the disk, the output is:

AUTOEXEC.BAT	is a directory?: false
boot.ini	is a directory?: false
Bootfont.bin	is a directory?: false
CONFIG.SYS	is a directory?: false
Documents and Settings	is a directory?: false
EasyShareInstall.log	is a directory?: false
Intel	is a directory?: false
IO.SYS	is a directory?: false
MSDOS.SYS	is a directory?: false
NTDETECT.COM	is a directory?: false
ntldr	is a directory?: false
pagefile.sys	is a directory?: false
Program Files	is a directory?: false
Programmi	is a directory?: false
RECYCLER	is a directory?: false
System Volume Information	is a directory?: false
VritualRoot	is a directory?: false
WINDOWS	is a directory?: false

this output shows the problem I have spotted:
here infact any file is treated like a file i.e. not a directory while 

Documents and Setting 
Intel
Program Files
Programmi
WINDOWS

are directories. The result is similar with any other path (either
absolute like "/Documents and Settings/program Files" or relative like
"../../".
The correct behaviour of the program is obtained only if I use "."

my OS is Windows XP
and I compiled the code with Eclipse IDE


-- 

questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news segnala gli abusi ad abuse@newsland.it

[toc] | [prev] | [next] | [standalone]

#9876

On 11/12/2011 9:04 AM, Alexo wrote:
>[...]
> The correct behaviour of the program is obtained only if I use "."

	import java.io.File;
	public class Alexo {
	    public static void main(String[] unused) {
	        tryit(".");
	        tryit("\\");
	    }
	    private static void tryit(String start) {
	        System.out.println("Starting String:\t" + start);
	        File begin = new File(start);
	        System.out.println("Starting File:\t" + begin);
	        for (File child : begin.listFiles()) {
	            char file = child.isFile() ? 'Y' : 'N';
	            char dir = child.isDirectory() ? 'Y' : 'N';
	            System.out.println("File? " + file + ", Dir? " + dir
	                    + "\t" + child);
	        }
	        System.out.println();
	    }
	}

Starting String:        .
Starting File:        .
File? N, Dir? Y        .\build
File? Y, Dir? N        .\build.xml
File? N, Dir? Y        .\coverage
File? Y, Dir? N        .\manifest.mf
File? N, Dir? Y        .\nbproject
File? N, Dir? Y        .\src
File? N, Dir? Y        .\test

Starting String:        \
Starting File:        \
File? Y, Dir? N        \AUTOEXEC.BAT
File? Y, Dir? N        \boot.ini
File? Y, Dir? N        \BOOTSECT.DOS
File? N, Dir? Y        \Config.Msi
File? Y, Dir? N        \CONFIG.SYS
File? N, Dir? Y        \djgpp
File? N, Dir? Y        \Documents and Settings
File? N, Dir? Y        \DRIVERS
File? N, Dir? Y        \I386
File? Y, Dir? N        \INSTALL.LOG
File? Y, Dir? N        \IO.SYS
File? Y, Dir? N        \IPH.PH
File? N, Dir? Y        \Media
File? Y, Dir? N        \MSDOS.SYS
File? N, Dir? Y        \My Music
File? Y, Dir? N        \net_save.dna
File? Y, Dir? N        \NTDETECT.COM
File? Y, Dir? N        \ntldr
File? N, Dir? Y        \NVIDIA
File? Y, Dir? N        \pagefile.sys
File? N, Dir? Y        \Program Files
File? N, Dir? Y        \RECYCLER
File? N, Dir? Y        \System Volume Information
File? N, Dir? Y        \TEMP
File? Y, Dir? N        \uninstall.log
File? N, Dir? Y        \WINDOWS
File? N, Dir? Y        \WINNT
File? N, Dir? Y        \WUTemp

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9880

hei Eric your code works, but where is the trouble in mine?


-- 

questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news segnala gli abusi ad abuse@newsland.it

[toc] | [prev] | [next] | [standalone]

#9881

Alexo wrote:

> hei Eric your code works, but where is the trouble in mine?
> 
> 

I think you've been told, here is the problem. You get the list of the "/" 
directory with the:
    File f = new File("/");

which is the wanted list of filenames. 
And then you're trying to take something out of the "." directory, each time 
you go through:
    file_array[i] = new File("." + "\\" + content[i]);
 



-- 
Zlatko

[toc] | [prev] | [next] | [standalone]

#9882

On 11/12/2011 10:17 AM, Alexo wrote:
> hei Eric your code works, but where is the trouble in mine?

     No idea.  You've shown us part (well, most) of your code, but
you haven't given a description of how you've used it.  You've
said things like "try to change the path" and "when I try to
change the path," but that's not precise enough to allow me or
someone else to duplicate your actions.

     Observe an important difference between my example and yours:
Yours is "Here's the code, but you'll need instructions for running
it," while mine is "Here's the code, entirely self-contained."
Do you see why one is easier to diagnose than the other?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9849

alelvb@inwind.it <alelvb@inwind.it> wrote:
> public class Main {
>    public static void main(String[] args){
>       File f = new File(".");        // try to change the path

...

>       for(int i=0; i<content.length; i++){
>           file_array[i] = new File("." + "\\" + content[i]);

First of all, did you change the path also here?
   or better: define a variable and use it in both spots.

Second, hardcoding "\\" is the worst approach at assembling a
  file name from components.  See the docu for File class for
  a static field that contains the appropriate separator char
  for the current platform.  For test code, "/" is often good 
  enough (even on Windows).

[toc] | [prev] | [next] | [standalone]

#9851

> > public class Main {
> >    public static void main(String[] args){
> >       File f = new File(".");        // try to change the path
>
> ...
>
> >       for(int i=0; i<content.length; i++){
> >           file_array[i] = new File("." + "\\" + content[i]);

> First of all, did you change the path also here?
>    or better: define a variable and use it in both spots.

Yes, I know that I'd have had used a variable.
You can remove the "." + "\\" + string and the code will work out the
same.

> Second, hardcoding "\\" is the worst approach at assembling a
>   file name from components.  See the docu for File class for
>   a static field that contains the appropriate separator char
>   for the current platform.  For test code, "/" is often good
>   enough (even on Windows).

do you mean that a path like C:\Documents and Settings\Program Files
in Java can be inputed like C:/Documents and Settings/Program Files
even when running on Windows?
ok it's good to know it

[toc] | [prev] | [next] | [standalone]

#9852

On 11/11/2011 12:42 PM, alelvb@inwind.it wrote:
>> Second, hardcoding "\\" is the worst approach at assembling a
>>    file name from components.  See the docu for File class for
>>    a static field that contains the appropriate separator char
>>    for the current platform.  For test code, "/" is often good
>>    enough (even on Windows).
>
> do you mean that a path like C:\Documents and Settings\Program Files
> in Java can be inputed like C:/Documents and Settings/Program Files
> even when running on Windows?

It works.

Arne

[toc] | [prev] | [next] | [standalone]

#9859

On Friday, November 11, 2011 8:25:11 AM UTC-8, Andreas Leitgeb wrote:
> ale...@inwind.it <ale...@inwind.it> wrote:
> > public class Main {
> >    public static void main(String[] args){
> >       File f = new File(".");        // try to change the path
> 
> ...
> 
> >       for(int i=0; i<content.length; i++){
> >           file_array[i] = new File("." + "\\" + content[i]);
> 
> First of all, did you change the path also here?
>    or better: define a variable and use it in both spots.
> 
> Second, hardcoding "\\" is the worst approach at assembling a
>   file name from components.  See the docu for File class for
>   a static field that contains the appropriate separator char
>   for the current platform.  For test code, "/" is often good 
>   enough (even on Windows).

Or you could use one of:
<http://docs.oracle.com/javase/7/docs/api/java/io/File.html#File(java.io.File, java.lang.String)>
or 
<http://docs.oracle.com/javase/7/docs/api/java/io/File.html#File(java.lang.String, java.lang.String)>

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9864

On 11/11/2011 11:25 AM, Andreas Leitgeb wrote:
> alelvb@inwind.it<alelvb@inwind.it>  wrote:
>> public class Main {
>>     public static void main(String[] args){
>>        File f = new File(".");        // try to change the path
>
> ...
>
>>        for(int i=0; i<content.length; i++){
>>            file_array[i] = new File("." + "\\" + content[i]);
>
> First of all, did you change the path also here?
>     or better: define a variable and use it in both spots.
>
> Second, hardcoding "\\" is the worst approach at assembling a
>    file name from components.  See the docu for File class for
>    a static field that contains the appropriate separator char
>    for the current platform.  For test code, "/" is often good
>    enough (even on Windows).

     Even better is to forgo the silly string-bashing and let File
figure it out:

	File parentDir = ...;
	File childFile = new File(parentDir, "child");

IMHO, Java errs in exposing any "path separator" at all, because
it just encourages string-bashing.  Note that in some file systems
there is no such thing as a "path separator;" on one such I had
files with names like

	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22

... and even this example doesn't show the full glory(?) of the syntax,
which could also supply host names, user names, and passwords -- all
as part of what a File *ought* to be able to manage.

     (In the O.P.'s specific case, using listFiles() instead of list()
would simplify things a good deal.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9865

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 11/11/2011 11:25 AM, Andreas Leitgeb wrote:
>> alelvb@inwind.it<alelvb@inwind.it>  wrote:
>>>  file_array[i] = new File("." + "\\" + content[i]);
>
>      Even better is to forgo the silly string-bashing and let File
> figure it out:
> 	File parentDir = ...;
> 	File childFile = new File(parentDir, "child");

Indeed a good remark.

It reminds me also of the caveat from old DOS days, where .\foo.exe
wouldn't work, if the current directory (containing foo.exe) was a
drive's root directory, as root directories just didn't have a "."
entry.
Is that still so? I don't have a Windows machine at hand right now to
test.

> IMHO, Java errs in exposing any "path separator" at all, because
> it just encourages string-bashing.  Note that in some file systems
> there is no such thing as a "path separator;" on one such I had
> files with names like
> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22

Such beasts still exist in the wild?
Or was it something embedded like e.g. on a smartcard?

[toc] | [prev] | [next] | [standalone]

#9874

On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>> [...]   Note that in some file systems
>> there is no such thing as a "path separator;" on one such I had
>> files with names like
>> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>
> Such beasts still exist in the wild?
> Or was it something embedded like e.g. on a smartcard?

http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming

     "A fossil!" I hear you cry, "A dried relic of prehistory!"
Yet, according to

http://en.wikipedia.org/wiki/OpenVMS#Major_release_timeline

... there was a new release (V8.4) just over a year ago.  The V7.0
version was roughly contemporaneous with the first release of Java.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9887

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>> [...]   Note that in some file systems
>>> there is no such thing as a "path separator;" on one such I had
>>> files with names like
>>> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>> Such beasts still exist in the wild?
>> Or was it something embedded like e.g. on a smartcard?
> http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
>      "A fossil!" I hear you cry, "A dried relic of prehistory!"

I'm not the type who would cry out about it, but I admit, I did think
something more or less similar.

> Yet, according to
> http://en.wikipedia.org/wiki/OpenVMS#Major_release_timeline
> ... there was a new release (V8.4) just over a year ago.  The V7.0
> version was roughly contemporaneous with the first release of Java.

I also admit, I'm surprised that at least Java 6 appears to be available
for it. (result of brief googling)

[toc] | [prev] | [next] | [standalone]

#9889

On 11/12/2011 5:09 PM, Andreas Leitgeb wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid>   wrote:
>>>> [...]   Note that in some file systems
>>>> there is no such thing as a "path separator;" on one such I had
>>>> files with names like
>>>> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>>> Such beasts still exist in the wild?
>>> Or was it something embedded like e.g. on a smartcard?
>> http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
>>       "A fossil!" I hear you cry, "A dried relic of prehistory!"
>
> I'm not the type who would cry out about it, but I admit, I did think
> something more or less similar.

I do not consider version numbers prehistoric relics.

:-)

Note that:
* ODS-5 file systems are case insensitive case preserving (Windows
   style) unlike ODS-2 that is case insensitive uppercasing (DOS style)
* Java actually supports both native syntax and traditional
   *nix / syntax for filenames

import java.io.*;

public class Disp {
     public static void show(String fnm) throws IOException {
         BufferedReader br = new BufferedReader(new FileReader(fnm));
         String line;
         while((line = br.readLine()) != null) {
             System.out.println(line);
         }
         br.close();
     }
     public static void main(String[] args) throws Exception {
         show("DISK2:[ARNE]HELLOWORLD.JAVA");
         show("/disk2/arne/helloworld.java");
     }
}

actually displays the same file twice.

>> Yet, according to
>> http://en.wikipedia.org/wiki/OpenVMS#Major_release_timeline
>> ... there was a new release (V8.4) just over a year ago.  The V7.0
>> version was roughly contemporaneous with the first release of Java.
>
> I also admit, I'm surprised that at least Java 6 appears to be available
> for it. (result of brief googling)

6.0-3 which is equivalent of Oracle 6.0u27 was released last month.

But no 1.7 yet.

Arne

[toc] | [prev] | [next] | [standalone]

#9893

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/12/2011 5:09 PM, Andreas Leitgeb wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>>>> Eric Sosman<esosman@ieee-dot-org.invalid>   wrote:
>>>>> [...]   Note that in some file systems
>>>>> there is no such thing as a "path separator;" on one such I had
>>>>> files with names like
>>>>> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>>>> Such beasts still exist in the wild?
>>> http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
>>>       "A fossil!" I hear you cry, "A dried relic of prehistory!"
>> I'm not the type who would cry out about it, but I admit, I did think
>> something more or less similar.
> I do not consider version numbers prehistoric relics.

Of course not those... (I think I've seen them even in some modern
filesystems with versioning support).
But I do consider the brackets enclosing the directory part of a
file's path to be such. (namely prehistoric relics)

> * Java actually supports both native syntax and traditional
>    *nix / syntax for filenames

So that gets us back to the start:
 Just using "/" as dir-separator is very likely to get you far enough.

[toc] | [prev] | [next] | [standalone]

#9895

On 11/12/2011 8:28 PM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 11/12/2011 5:09 PM, Andreas Leitgeb wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid>   wrote:
>>>> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>>>>> Eric Sosman<esosman@ieee-dot-org.invalid>    wrote:
>>>>>> [...]   Note that in some file systems
>>>>>> there is no such thing as a "path separator;" on one such I had
>>>>>> files with names like
>>>>>> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>>>>> Such beasts still exist in the wild?
>>>> http://en.wikipedia.org/wiki/Files-11#Disk_organization_and_naming
>>>>        "A fossil!" I hear you cry, "A dried relic of prehistory!"
>>> I'm not the type who would cry out about it, but I admit, I did think
>>> something more or less similar.
>> I do not consider version numbers prehistoric relics.
>
> Of course not those... (I think I've seen them even in some modern
> filesystems with versioning support).
> But I do consider the brackets enclosing the directory part of a
> file's path to be such. (namely prehistoric relics)

So / is modern but [] is oldfashioned.

Are there any objective reason for that?

>> * Java actually supports both native syntax and traditional
>>     *nix / syntax for filenames
>
> So that gets us back to the start:
>   Just using "/" as dir-separator is very likely to get you far enough.

It will get you to where a user actually specify a filename
in normal native syntax.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web