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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9901

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 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?

In a way, I envy you (Eric and Arne) for your wider horizon. I've 
never got in touch with it, and haven't found any official ISO image
or zip or tarball, either, to get my own hands on it. (I guess the
"open" in "openvms" is more like the one in "openmotif", than the
one in "openoffice". :-)

That said, I do have my "personal reasons" for calling openvms 
essentially irrelevant for new software development (a bit like
pre-X MacOS, CP/M - not to mention my sharp pocket-computers from
last decade's eighties).  I'm not going to write a thesis on
scientific classification of operating systems by their "obsolete-
ness", though.

It's the same principial reason, btw., that makes others discard
anything non-MS.

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

#9902

On Sat, 12 Nov 2011 20:42:21 -0500, Arne Vajhøj wrote:

> 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.
>
... but its best to get into the habit of assembling a filename along the 
lines of 
	dirNameList + File.separator + fileName

rather than using
	dirNameList + "/" + fileName


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#9905

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Sat, 12 Nov 2011 20:42:21 -0500, Arne Vajhøj wrote:
>>>> * 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.
> ... but its best to get into the habit of assembling a filename along the 
> lines of 
> 	dirNameList + File.separator + fileName
> rather than using
> 	dirNameList + "/" + fileName

What I picked up from this semi off topic thread is, that the particular
distinction is utterly irrelevant, and the only portable (in Java's sense)
way to do file-name manipulations would be to wrap the original name in a
File object, and stick to File methods as much as possible, turning back
to a String only at the end of all the jugglings.

If portability means merely "runs on Windows and various unixoids", then
File.separator is at least better than "\\".

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

#9888

On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>> 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?

Yes !

$ type DISK2:[ARNE]HELLOWORLD.JAVA;1
public class HelloWorld {
     public static void main(String[] args) throws Exception {
         System.out.println("Hello world!");
     }
}
$ javac helloworld.java
$ java "HelloWorld"
Hello world!

Arne

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

#9892

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>> 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?

> $ type DISK2:[ARNE]HELLOWORLD.JAVA;1
[...]

This doesn't yet answer the "in the wild"-part:   Is that a machine
still in productive use, or is it merely running under a VAX-emulator
on a PC (just for playing around)? :-)

Anyway, as it seems (gathered from googled pages), java is able to
translate paths like "/disk2/arne/helloworld.java" to what the
system understands, so there'd not really be much of a need for a Java
programmer to explicitly deal with those path construction pecularities.

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

#9894

On 11/12/2011 8:15 PM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid>   wrote:
>>>> 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?
>
>> $ type DISK2:[ARNE]HELLOWORLD.JAVA;1
> [...]
>
> This doesn't yet answer the "in the wild"-part:   Is that a machine
> still in productive use, or is it merely running under a VAX-emulator
> on a PC (just for playing around)? :-)

There are still some in production use.

The one used is hobbyist only though.

> Anyway, as it seems (gathered from googled pages), java is able to
> translate paths like "/disk2/arne/helloworld.java" to what the
> system understands, so there'd not really be much of a need for a Java
> programmer to explicitly deal with those path construction pecularities.

I consider it very relevant for an Java app to be able to handle
native file name syntax - after all that is what most likely
will be specified in config files and manually entered.

Arne

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

#9903

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/12/2011 8:15 PM, Andreas Leitgeb wrote:
>> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>>> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>>>> Eric Sosman<esosman@ieee-dot-org.invalid>   wrote:
>>>>> 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?
>>> $ type DISK2:[ARNE]HELLOWORLD.JAVA;1
>> This doesn't yet answer the "in the wild"-part:   Is that a machine
>> still in productive use, or is it merely running under a VAX-emulator
>> on a PC (just for playing around)? :-)
> There are still some in production use.
> The one used is hobbyist only though.

These aren't sufficient criteria for "non-obsolete" in my own dictionary ;)

>> Anyway, as it seems (gathered from googled pages), java is able to
>> translate paths like "/disk2/arne/helloworld.java" to what the
>> system understands, so there'd not really be much of a need for a Java
>> programmer to explicitly deal with those path construction pecularities.
> I consider it very relevant for an Java app to be able to handle
> native file name syntax - after all that is what most likely
> will be specified in config files and manually entered.

If a Java application making use of "/"-heuristics on filenames was deployed
to an openvms platform, then likely those who deploy it will have to explain
to the users how to specify paths for that app.  That's bad luck for systems
on the waning side of their project life cycle.

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

#9896

On 11/12/2011 8:15 PM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 11/11/2011 10:21 PM, Andreas Leitgeb wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid>   wrote:
>>>> 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?
>
>> $ type DISK2:[ARNE]HELLOWORLD.JAVA;1
> [...]
>
> This doesn't yet answer the "in the wild"-part:   Is that a machine
> still in productive use, or is it merely running under a VAX-emulator
> on a PC (just for playing around)? :-)
>
> Anyway, as it seems (gathered from googled pages), java is able to
> translate paths like "/disk2/arne/helloworld.java" to what the
> system understands, so there'd not really be much of a need for a Java
> programmer to explicitly deal with those path construction pecularities.

     Speaking as a person who wrote code that tried to mediate
between VMS ("structured") file names and Unix ("just glob it") paths,
I am here to tell you that there are many subtle traps.  Version numbers
inevitably got garbled, if not "in translation" then "in manipulation"
on the other side of the fence.  The fact that the parent directory of

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

baffled innumerable Unixoid programs that thought they could just "take
everything before the rightmost separator" to get the parent's name.
Anybody who thinks the mapping is half a day's work has got another
think coming -- and weeks of unplanned labor, too.  I've got the scars.

     Common LISP supported a richer filename abstraction, one that could
handle Unix and DOS and Apollo and Mac and VMS and probably others I wot
not of.  Steele was certainly aware of LISP's capability (he made money
off a LISP book, after all), so Java's blinkered view is puzzling.

     IMHO, File is the second-sloppiest "everyday" core Java class,
losing out only to Date (if "losing" is the right word).

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

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

#9936

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>      Speaking as a person who wrote code that tried to mediate
> between VMS ("structured") file names and Unix ("just glob it") paths,
> I am here to tell you that there are many subtle traps.  Version numbers
> inevitably got garbled, if not "in translation" then "in manipulation"
> on the other side of the fence.  The fact that the parent directory of
>
> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
> was
> 	SYS$DISK:[USERS.ERIC]PROJECT.DIR;1
>
> baffled innumerable Unixoid programs that thought they could just "take
> everything before the rightmost separator" to get the parent's name.
> Anybody who thinks the mapping is half a day's work has got another
> think coming -- and weeks of unplanned labor, too.  I've got the scars.

I'm still wondering, how this effort was even worth it.

Dinosaur systems typically are left with the software that ran on them
since Jura, and "new SW" often means binary-patching the running
processes directly in memory, rather than deploying brand-new (i.e. less
than 10 years old) code onto them.    (Not entirely serious now. ;-)

Anyway, multiplying your effort for the task with the probability of
some random code going to be deployed on openvms makes it rather 
cheap after all. Cheaper than having to teach coders to write file
name manipulations portably beyond choice of separator char in the
first place.

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

#9952

On 11/13/2011 3:50 PM, Andreas Leitgeb wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>       Speaking as a person who wrote code that tried to mediate
>> between VMS ("structured") file names and Unix ("just glob it") paths,
>> I am here to tell you that there are many subtle traps.  Version numbers
>> inevitably got garbled, if not "in translation" then "in manipulation"
>> on the other side of the fence.  The fact that the parent directory of
>>
>> 	SYS$DISK:[USERS.ERIC.PROJECT]README.TXT;22
>> was
>> 	SYS$DISK:[USERS.ERIC]PROJECT.DIR;1
>>
>> baffled innumerable Unixoid programs that thought they could just "take
>> everything before the rightmost separator" to get the parent's name.
>> Anybody who thinks the mapping is half a day's work has got another
>> think coming -- and weeks of unplanned labor, too.  I've got the scars.
>
> I'm still wondering, how this effort was even worth it.

     In hindsight, you're right. We should have just ditched the
VMS port of our product on the grounds that the platform was too
ugly and/or baroque and/or expensive and/or unfamiliar.

     But, alas! We allowed ourselves to be influenced by the market,
instead of holding to our ideological purity. The fact that VMS was
the second most popular platform for our product (in one quarter it
actually took the top spot) caused the bean counters to insist that
we support it. Stupid bean counters!

> Dinosaur systems [...]

     Note that Unix is even older than VMS.

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

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

#9957

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 11/13/2011 3:50 PM, Andreas Leitgeb wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>> [...] baffled innumerable Unixoid programs that thought they could just
>>> "take everything before the rightmost separator" to get the parent's name.
>>> Anybody who thinks the mapping is half a day's work has got another
>>> think coming -- and weeks of unplanned labor, too.  I've got the scars.
>> I'm still wondering, how this effort was even worth it.
>      In hindsight, you're right. We should have just ditched the
> VMS port of our product on the grounds that the platform was too
> ugly and/or baroque and/or expensive and/or unfamiliar.
>      But, alas! We allowed ourselves to be influenced by the market,
> instead of holding to our ideological purity. The fact that VMS was
> the second most popular platform for our product (in one quarter it
> actually took the top spot) caused the bean counters to insist that
> we support it. Stupid bean counters!

:-)   (I appreciate good irony)

How recent was your porting activity? (months, years or decades?)

>> Dinosaur systems [...]
>      Note that Unix is even older than VMS.
Yeah, it's also older than OS/2...

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

#9962

On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
> [... concerning VMS ...]
>
> How recent was your porting activity? (months, years or decades?)

     My active involvement started in the late 1980's and continued
through the mid-1990's.  After I left the company in 1998, they
re-engaged me as an out-of-hours independent contractor to do yet
a little more maintenance work.  So I guess the time range was
between 1.5-2.5 decades ago.  VMS' development, of course, did not
end when my involvement with it ceased.

     Still, my principal point is not about support of "dinosaur
systems," but that even the most modern systems we know today will
eventually be dinosaurs.  The File class offers an abstraction,
which File.pathSeparatorChar promptly breaches: "Java refuses to
support any system whose file names do not consist of sequences
of component names separated by a single distinguished character."
Given that File offers ways to assemble and disassemble file names
without this knowledge, was exposing the knowledge a bright idea?
Is a programmer better off using that exposed implementation, or
sticking to the higher-level abstraction?

     <Falling into a prophetic trance>: The year 2014 will see the
introduction of a brand-new paradigm for thinking about persistent
storage, one in which names cannot be so trivially encoded.  By 2017,
systems based on this new scheme will have swept away all the naive
file-naming notions of Unix, MS-DOS, VMS, AIX, and VM; even URI's
will be on their way out.  Will Java be part of the problem, or part
of the solution?

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

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

#9964

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
>> [... concerning VMS ...]
>> How recent was your porting activity? (months, years or decades?)
> [ Answer: essentially last century ]
Do you think, the same management would make 
that decisions again nowadays for nowadays'
marketshare of VMS?

Anyway, I agree that using the abstraction that File provides
is principially better than doing one's own path-arithmetics.
I also agree, that providing the pathSeparator impedes the
abstraction.

But then again, if that weren't there, then those who don't
hardcode "\\", anyway, would probably query the OS, and do a
short if-elseif-chain for the OS's they know of to pick some
pathSeparator, or construct some File("a","b"), and somehow
(heuristically) extract the pathSeparator from that.

Sometimes, abstraction also gets into your way: how would you
model a relative path that starts with going one or more levels
up?   I think to remember that MacOS (before 10) didn't have
such a concept.  Did(/does) VMS?

>      <Falling into a prophetic trance>: The year 2014 will see the
> introduction of a brand-new paradigm for thinking about persistent
> storage, one in which names cannot be so trivially encoded.  By 2017,
> systems based on this new scheme will have swept away all the naive
> file-naming notions of Unix, MS-DOS, VMS, AIX, and VM; even URI's
> will be on their way out.  Will Java be part of the problem, or part
> of the solution?

A very good argument.  I doubt, however, that even those using the
current File API in the cleanest possible way, will necessarily be
fit for those future filesystem changes.

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

#9969

On 11/15/2011 9:17 AM, Andreas Leitgeb wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>> On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
>>> [... concerning VMS ...]
>>> How recent was your porting activity? (months, years or decades?)
>> [ Answer: essentially last century ]
> Do you think, the same management would make
> that decisions again nowadays for nowadays'
> marketshare of VMS?

     Would they decide to sell product on one of the most popular
platforms in their ecosystem?  I hope so!

     Would they decide to drop a platform because it would mostly
disappear within, oh, sixty-plus financial quarters?  I hope not!

> Anyway, I agree that using the abstraction that File provides
> is principially better than doing one's own path-arithmetics.
> I also agree, that providing the pathSeparator impedes the
> abstraction.

> Sometimes, abstraction also gets into your way: how would you
> model a relative path that starts with going one or more levels
> up?

	File child = ...;
	File parent = child.getParent();
	File grandparent = parent.getParent();
	...

> I think to remember that MacOS (before 10) didn't have
> such a concept.  Did(/does) VMS?

     Can't answer for MacOS.  In VMS, sure: A file or directory was
either at the topmost level of its file system or it was contained
in a parent directory, and you could find the parent, and so on.

>>       <Falling into a prophetic trance>: The year 2014 will see the
>> introduction of a brand-new paradigm for thinking about persistent
>> storage, one in which names cannot be so trivially encoded.  By 2017,
>> systems based on this new scheme will have swept away all the naive
>> file-naming notions of Unix, MS-DOS, VMS, AIX, and VM; even URI's
>> will be on their way out.  Will Java be part of the problem, or part
>> of the solution?
>
> A very good argument.  I doubt, however, that even those using the
> current File API in the cleanest possible way, will necessarily be
> fit for those future filesystem changes.

     True: Java has lots of other built-in limitations that make it
unsuitable or at least uncomfortable for "advanced" (or even "large")
files.  I guess the Java answer is "We'll pretend the super-files are
databases and make you go through adapters to get at them ..."

     </smiley></rant> Oh, did I forget to open these?

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

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

#9972

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 11/15/2011 9:17 AM, Andreas Leitgeb wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>> On 11/14/2011 12:38 PM, Andreas Leitgeb wrote:
>>>> [... concerning VMS ...]
>>>> How recent was your porting activity? (months, years or decades?)
>>> [ Answer: essentially last century ]
>> Do you think, the same management would make
>> that decisions again nowadays for nowadays'
>> marketshare of VMS?
> Would they decide to sell product on one of the most popular
> platforms in their ecosystem?

If it is that, I'd finally be curious about what ecosystem
it is.

>> Sometimes, abstraction also gets into your way: how would you
>> model a relative path that starts with going one or more levels
>> up?

Not sure if your answer was covered by the <smilie>-tag,
or whether my question was indeed unclear.

If in a VMS-shell you're curently in directory
  data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n]foo.dir
and wanted to access the file 
  data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n.bar]xyz.txt
would you need to specify the complete path to xyz.txt, or
is there some syntactic pendant to "../bar/xyz.txt" in VMS?

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

#9973

On 11/16/2011 7:14 AM, Andreas Leitgeb wrote:
>[...]
> If in a VMS-shell you're curently in directory
>    data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n]foo.dir
> and wanted to access the file
>    data:[a.b.c.d.e.f.g.h.i.j.k.l.m.n.bar]xyz.txt
> would you need to specify the complete path to xyz.txt, or
> is there some syntactic pendant to "../bar/xyz.txt" in VMS?

     Sorry; I don't remember.  I *do* remember, though that there
is no such thing as being "in" a directory.  VMS does not have a
Unix-oid notion of "current working directory," but instead has a
"default file specification."  If you hand the system an incomplete
file name, the missing pieces are filled in from the DFS.  Thus,
the resolution of incomplete names is a lexical operation, not a
"navigational" operation.

     Usually this difference does not obtrude itself upon the user's
consciousness, but there are situations where it becomes important.
For example, the "data" in your example could be a "logical name"
with multiple translations: DISK1:[ANDREAS],DISK2:[READONLY], for
example.  You could then tell javac to compile DATA:[.SOURCE]FOO.JAVA
and DATA:[.SOURCE]BAR.JAVA, and javac would happily find your locally-
modified DISK1:[ANDREAS.SOURCE]FOO.JAVA and the still-in-the-repository
DISK2:[READONLY.SOURCE]BAR.JAVA.  It's something like the way a Unix
shell follows the PATH variable, except generalized for all files
instead of being limited just to executables.

     ... but note what this does to the notion of "current directory."
DATA:[.SOURCE]FOO.JAVA and DATA:[.SOURCE]BAR.JAVA have different
parent directories, DISK1:[ANDREAS] and DISK2:[READONLY], respectively.
The idea of being "in" a particular directory may not stand scrutiny.

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

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

#9866

On 11/11/11 5:38 PM, Eric Sosman wrote:
> 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.
Ah, good old VMS.

Revision number 22 of README.TXT in the PROJECT directory in the ERIC 
directory in the USERS directory :-)

The way I describe VMS CLI is to contrast it with Linux.  in Linux, you 
give "garbled english" commands and get well-formed english responses. 
In VMS the converse is true.

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

#9947

On 2011-11-12 01:38:55 +0000, Eric Sosman said:

> 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");

You don't need that, either, if all you're doing is enumerating 
directory contents like the OP. File exposes a method for obtaining the 
entries of a directory *as File objects* already, so reconstructing 
File objects from the base names and parent directory is pretty much 
wasted effort.

Have a look at the listFiles() method.

-o

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

#9949

Owen Jacobson wrote:
> Eric Sosman said:
... 
>>      Even better is to forgo the silly string-bashing and let File
>> figure it out:
>> 
>> 	File parentDir = ...;
>> 	File childFile = new File(parentDir, "child");
> 
> You don't need that, either, if all you're doing is enumerating 
> directory contents like the OP. File exposes a method for obtaining the 
> entries of a directory *as File objects* already, so reconstructing 
> File objects from the base names and parent directory is pretty much 
> wasted effort.
> 
> Have a look at the listFiles() method.
> 
> -o

When quoting him, you left out the part of Eric's post that said:
> (In the O.P.'s specific case, using listFiles() instead of list() 
> would simplify things a good deal.) 

-- 
Lew

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

#9873

On Fri, 11 Nov 2011 05:45:29 -0800 (PST), alelvb@inwind.it wrote,
quoted or indirectly quoted someone who said :

>		File f = new File(".");        // try to change the path

You can discover the value of the set path= environment variable with
System.getEnv( "path" ) but you cannot change it.

You can't change the CWD inside Java.  It stays constant for your run.
Yo would have spawn shell scripts to get that effect.

The File class has lots of surprises.  See

http://mindprod.com/jgloss/filesanddirectories.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Windows is a case-insensitive operating system,
but that does not mean you can forget about case. 
For example, Let us assume you have a file called
Abc.txt in C:\temp, and a file called 
aBc.txt in D:\temp and you type 
copy C:\temp\abC.txt D:\temp. What is the name of the file in 
D:\temp when you are done?
1) Abc.txt 2) aBc.txt 3) abC.txt 4) abc.txt 5) ABC.txt
Hint, the answer rhymes with the most popular word in advertising. 

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web