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

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

CLI Java Glitch

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

Contents

  CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-20 14:24 -0700
    Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-20 14:48 -0700
    Re: CLI Java Glitch Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-20 18:49 -0300
    Re: CLI Java Glitch Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-20 22:09 +0000
      Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-21 10:16 +1000
        Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:49 +0100
          Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-21 15:11 -0700
            Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 16:37 -0700
              Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-21 17:54 -0700
                Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 20:58 -0400
                  Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-21 18:14 -0700
                    Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:19 -0400
                      Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-22 19:45 -0700
                        Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 23:17 -0400
                          Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-22 20:25 -0700
                            Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 23:38 -0400
                              Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-07-23 09:09 -0700
                    Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-07-22 18:41 +1000
                      Re: CLI Java Glitch Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-25 11:25 +0000
              Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-22 09:02 -0700
                Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 10:12 -0700
                  Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-22 10:39 -0700
            Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-22 09:50 -0700
            Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-22 19:44 +0100
              Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 12:31 -0400
                Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-23 23:04 +0100
                  Re: CLI Java Glitch Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-23 21:40 -0700
                  Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-24 09:43 -0400
            Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 12:24 -0400
              Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-23 14:32 -0700
              Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-24 09:12 -0700
                Re: CLI Java Glitch Bent C Dalager <bcd@pvv.ntnu.no> - 2011-06-24 22:49 +0000
                  Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-26 20:29 -0700
          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 16:29 -0700
          Re: CLI Java Glitch Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-22 11:54 +0100
            Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 10:16 -0700
              Re: CLI Java Glitch Patricia Shanahan <pats@acm.org> - 2011-06-22 11:06 -0700
                Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 11:46 -0700
                  Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 12:50 -0700
                    Re: CLI Java Glitch Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-23 15:23 +0100
                      Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-23 08:58 -0700
                    Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-24 08:58 -0700
                      Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-24 11:36 -0700
                  Re: CLI Java Glitch Paul Cager <paul.cager@googlemail.com> - 2011-06-22 14:45 -0700
                  Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-22 23:29 +0100
                    Re: CLI Java Glitch Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-22 18:08 -0700
                    Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-23 23:20 +0100
                      Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-24 10:28 +1000
                        Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-25 22:58 +0100
                          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-26 20:31 -0700
                    Re: CLI Java Glitch lewbloch <lewbloch@gmail.com> - 2011-06-24 09:00 -0700
                  Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:33 -0400
                  Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:38 -0400
                  Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:41 -0400
            Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-22 20:00 +0100
              Re: CLI Java Glitch Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-23 15:18 +0100
            Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:29 -0400
          Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-23 11:40 +1000
            Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-23 20:21 +1000
            Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-23 09:00 -0700
              Re: CLI Java Glitch Esmond Pitt <esmond.pitt@bigpond.com> - 2011-06-24 10:24 +1000
      Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:52 +0100
    Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 19:11 -0400
      Re: CLI Java Glitch Lew Bloch <lewisbloch@google.com> - 2011-06-20 16:25 -0700
        Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 19:45 -0400
          Re: CLI Java Glitch Lew Bloch <lewisbloch@google.com> - 2011-06-20 18:28 -0700
          Ping: Lew Bloch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 23:26 -0400
            Re: Ping: Lew Bloch Lew Bloch <lewisbloch@google.com> - 2011-06-21 10:25 -0700
              Re: Ping: Lew Bloch Jeff Higgins <jeff@invalid.invalid> - 2011-06-21 14:36 -0400
        Re: CLI Java Glitch Patricia Shanahan <pats@acm.org> - 2011-06-20 17:02 -0700
          Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 20:37 -0400
            Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-20 20:44 -0400
              Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:45 +0100
    Re: CLI Java Glitch Roedy Green <see_website@mindprod.com.invalid> - 2011-06-20 16:55 -0700
      Re: CLI Java Glitch Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-20 20:44 -0400
        Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-20 19:26 -0700
        Re: CLI Java Glitch Paul Cager <paul.cager@googlemail.com> - 2011-06-21 02:34 -0700
          Re: CLI Java Glitch Silvio <silvio@moc.com> - 2011-06-21 16:50 +0200
          Re: CLI Java Glitch "Gavino" <invalid@invalid.invalid> - 2011-06-21 21:35 +0200
        Re: CLI Java Glitch Roedy Green <see_website@mindprod.com.invalid> - 2011-06-21 11:59 -0700
          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 13:03 -0700
            Re: CLI Java Glitch BGB <cr88192@hotmail.com> - 2011-06-21 14:21 -0700
        Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:45 -0400
    Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-20 19:29 -0700
    Re: CLI Java Glitch Tom Anderson <twic@urchin.earth.li> - 2011-06-21 22:42 +0100
      Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-21 14:48 -0700
      Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:47 -0400
    Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-21 21:52 -0400
      Re: CLI Java Glitch Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-22 07:56 -0300
        Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-22 08:02 -0400
          Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 10:18 -0700
            Re: CLI Java Glitch Jeff Higgins <jeff@invalid.invalid> - 2011-06-22 15:01 -0400
              Re: CLI Java Glitch Gene Wirchenko <genew@ocis.net> - 2011-06-22 12:54 -0700
            Re: CLI Java Glitch Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-22 18:52 -0300
              Re: CLI Java Glitch Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 17:50 -0400
            Re: CLI Java Glitch Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 15:13 -0400

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

#5436 — CLI Java Glitch

Dear Java'ers:

     Given

class HelloWorld
   {
   public static void main(String[] args)
      {
      System.out.println("Hello, world!");
      }
   }

is there any way around the following?

C:\cbs2dev\test>java helloworld
Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
(wrong nam
e: HelloWorld)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(Unknown Source)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$000(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: helloworld.  Program will exit.

C:\cbs2dev\test>java HelloWorld
Hello, world!

     Most commands in a Windows system are case-insensitive so any are
liable to be typed that way.

     I find it weird that it does apparently know the correct name and
includes it in the error message.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#5438

On 6/20/2011 2:24 PM, Gene Wirchenko wrote:
>       Most commands in a Windows system are case-insensitive so any are
> liable to be typed that way.
>
>       I find it weird that it does apparently know the correct name and
> includes it in the error message.

Java classes are case-sensitive; the argument to java is not a file to 
run but a class whose main method should be called. It is roughly 
equivalent to arguing that, since Windows is case-insensitive, `echo Hi' 
and `echo hi' should both print out the same thing.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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

#5439

On 11-06-20 06:24 PM, Gene Wirchenko wrote:
> Dear Java'ers:
> 
>      Given
> 
> class HelloWorld
>    {
>    public static void main(String[] args)
>       {
>       System.out.println("Hello, world!");
>       }
>    }
> 
> is there any way around the following?
> 
> C:\cbs2dev\test>java helloworld
> Exception in thread "main" java.lang.NoClassDefFoundError: helloworld
> (wrong nam
> e: HelloWorld)
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClassCond(Unknown Source)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at java.security.SecureClassLoader.defineClass(Unknown Source)
>         at java.net.URLClassLoader.defineClass(Unknown Source)
>         at java.net.URLClassLoader.access$000(Unknown Source)
>         at java.net.URLClassLoader$1.run(Unknown Source)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(Unknown Source)
>         at java.lang.ClassLoader.loadClass(Unknown Source)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>         at java.lang.ClassLoader.loadClass(Unknown Source)
> Could not find the main class: helloworld.  Program will exit.
> 
> C:\cbs2dev\test>java HelloWorld
> Hello, world!
> 
>      Most commands in a Windows system are case-insensitive so any are
> liable to be typed that way.

The commands might be, but the arguments often are not. "HelloWorld" is
an argument.

>      I find it weird that it does apparently know the correct name and
> includes it in the error message.

It'll help you out if a class can be found that is, say, wrong only in
case. If you were to try "helloworld2", for example, it wouldn't
nominate "HelloWorld". It doesn't actually "know" the correct name,
obviously, but it can make a brainless stab at it to help you out.

AHS

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

#5442

On Mon, 20 Jun 2011 14:24:53 -0700, Gene Wirchenko wrote:

> Dear Java'ers:
> 
>      Given
> 
> class HelloWorld
>    {
>    public static void main(String[] args)
>       {
>       System.out.println("Hello, world!");
>       }
>    }
> 
> is there any way around the following?
>
Nope: out it down to the non-intuitive ways some OSen handle file names. 
There's a big difference between: 

(1) an OS that stores a file name as input but does caseless name 
comparisons when parsing a request to find a file (Windows from Win95 
onwards)

and

(2) one that converts file names to, say, upper case when they're stored 
and *then* does caseless comparisons. (DOS, Windows to 3.11)

or 

(3) one that stores file names as entered and does case-sensitive 
comparisons. (all UNIX family OSen)

The Java language system does case-sensitive comparisons between class 
names and the files that contain them when checking that a class name 
matches the file name that contains it or when the class-loader is 
looking for a classfile, so it will behave as a person used to case 2 or 
3 would expect, but you'd better get the case right if you're using a 
case 1 OS.


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

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

#5448

On 21/06/2011 8:09 AM, Martin Gregorie wrote:
>
> The Java language system does case-sensitive comparisons between class
> names and the files that contain them when checking that a class name
> matches the file name that contains it

Nitpicking, but it doesn't really do that, does it. It opens a .class 
file of the name the user specified, loads the class(es) it contains, 
and tries to find the classname it was looking for among those classes. 
It doesn't explicitly compare the filename and the classname. The 
operating system gave it HelloWorld.class in response to 
'helloworld.class' because that's how the OS file system happened to work.

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

#5491

On Tue, 21 Jun 2011, Esmond Pitt wrote:

> On 21/06/2011 8:09 AM, Martin Gregorie wrote:
>
>> The Java language system does case-sensitive comparisons between class
>> names and the files that contain them when checking that a class name
>> matches the file name that contains it
>
> Nitpicking, but it doesn't really do that, does it. It opens a .class 
> file of the name the user specified, loads the class(es) it contains, 
> and tries to find the classname it was looking for among those classes. 
> It doesn't explicitly compare the filename and the classname. The 
> operating system gave it HelloWorld.class in response to 
> 'helloworld.class' because that's how the OS file system happened to 
> work.

The way Java does this at the moment means that 'java helloworld', where 
there is no class 'helloworld', does different things on Windows depending 
on whether there is a class HelloWorld, hElLoWoRlD, HelloworlD, etc.

That seems pretty shoddy to me. If you're a case-sensitive program running 
on a case-insensitive operating system, i think it falls on you to pay 
special attention to case in your dealings with that system: when java 
opens a class file, it ought to check that the name of the file it's 
opened actually has the right case, and if it doesn't, discard it, and act 
as if it had got a file not found error from the operating system.

tom

-- 
No man ever steps in the same river twice, for it's not the same river
and he's not the same man. -- Heraclitus

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

#5495

On 6/21/11 2:49 PM, Tom Anderson wrote:
> On Tue, 21 Jun 2011, Esmond Pitt wrote:
>
>> On 21/06/2011 8:09 AM, Martin Gregorie wrote:
>>
>>> The Java language system does case-sensitive comparisons between class
>>> names and the files that contain them when checking that a class name
>>> matches the file name that contains it
>>
>> Nitpicking, but it doesn't really do that, does it. It opens a .class
>> file of the name the user specified, loads the class(es) it contains,
>> and tries to find the classname it was looking for among those
>> classes. It doesn't explicitly compare the filename and the classname.
>> The operating system gave it HelloWorld.class in response to
>> 'helloworld.class' because that's how the OS file system happened to
>> work.
>
> The way Java does this at the moment means that 'java helloworld', where
> there is no class 'helloworld', does different things on Windows
> depending on whether there is a class HelloWorld, hElLoWoRlD,
> HelloworlD, etc.
>
> That seems pretty shoddy to me. If you're a case-sensitive program
> running on a case-insensitive operating system, i think it falls on you
> to pay special attention to case in your dealings with that system:

Speaking of "shoddy", some might consider it "shoddy" to call the 
_operating system_ "case-insensitive" when in fact it's the _file 
system_ that is case-insensitive.

And even Unix variants can often be found using case-insensitive file 
systems, just as Windows can often be found using case-sensitive file 
systems (though probably less frequently than the case-insensitive/Unix 
scenario, since the Windows ecosystem is generally more homogeneous).

> when
> java opens a class file, it ought to check that the name of the file
> it's opened actually has the right case, and if it doesn't, discard it,
> and act as if it had got a file not found error from the operating system.

I don't believe that the error comes from the operating system.  The 
error comes from opening a file that matches (according to the rules of 
the file system) the name that was given, which succeeds (i.e. no 
error), but then failing to find a correctly-named class in that file. 
The error itself comes from Java, not from the operating system nor even 
the file system.

And frankly, I don't see how Java can do any better than that.  Even on 
a given OS, the file system itself may or may not be case-insensitive. 
The best Java can do is ask the file system to open the file that the 
user specified (exactly as the user specified it), and then if that 
succeeds to then look for the same-named class.

Short of making Java a case-insensitive language (which seems 
impractical at this point, whether or not anyone might have thought that 
a good idea from the outset), I don't see how Java could improve on the 
situation.  For better or worse, Java _is_ case-sensitive, which means 
that it definitely should be just as illegal for the user to specify 
"helloworld" as the class name when starting the program as it is for 
the programmer to specify "helloworld" as the class name when referring 
to it from code.

If Java is deficient in any way here, I'd say it's the inability to 
specify the .class file name separately from the name of the class 
itself, specifically because of the potential for this mis-match of 
casing rules.  But even that seems a stretch to me, especially since 
offering that option could encourage people naming their .class files 
something completely different than the class contained within 
(something I'd rather not see as a general practice :) ).

Pete

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

#5500

On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

[snip]

>Speaking of "shoddy", some might consider it "shoddy" to call the 
>_operating system_ "case-insensitive" when in fact it's the _file 
>system_ that is case-insensitive.

     Please do not nitpick.

[snip]

>I don't believe that the error comes from the operating system.  The 
>error comes from opening a file that matches (according to the rules of 
>the file system) the name that was given, which succeeds (i.e. no 
>error), but then failing to find a correctly-named class in that file. 
>The error itself comes from Java, not from the operating system nor even 
>the file system.

     Quite so.

>And frankly, I don't see how Java can do any better than that.  Even on 
>a given OS, the file system itself may or may not be case-insensitive. 
>The best Java can do is ask the file system to open the file that the 
>user specified (exactly as the user specified it), and then if that 
>succeeds to then look for the same-named class.

     I do.

          Search for the name in the case-insensitive filesystem.
          if number of files found=0
             throw file not found
          else if number of files found=1
             run the file found (regardless of case)
          else
             {
             Is one of the filename a match case-sensitively?
             if yes
                run that matching file
             else
                throw ambiguous name
             }

[snip]

>If Java is deficient in any way here, I'd say it's the inability to 
>specify the .class file name separately from the name of the class 
>itself, specifically because of the potential for this mis-match of 
>casing rules.  But even that seems a stretch to me, especially since 

     My suggestion would cover that ...

>offering that option could encourage people naming their .class files 
>something completely different than the class contained within 
>(something I'd rather not see as a general practice :) ).

... and prevent this.

Sincerely,

Gene Wirchenko

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

#5504

On 6/21/11 4:37 PM, Gene Wirchenko wrote:
> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>
> [snip]
>
>> Speaking of "shoddy", some might consider it "shoddy" to call the
>> _operating system_ "case-insensitive" when in fact it's the _file
>> system_ that is case-insensitive.
>
>       Please do not nitpick.

I have been known to nitpick, but making a distinction between operating 
system and file system is far from that.

> [...]
>            Search for the name in the case-insensitive filesystem.

You've already got a problem right there, since it's not really up to 
Java to decide whether it's dealing with a case-sensitive file system or 
not.  It shouldn't care.

>            if number of files found=0
>               throw file not found
>            else if number of files found=1
>               run the file found (regardless of case)

And you've got a problem there too: the name provided by the user is a 
_Java_ name, and the language _is_ case-sensitive.  It's an 
implementation error for Java to behave in a case-insensitive way.

>            else
>               {
>               Is one of the filename a match case-sensitively?
>               if yes
>                  run that matching file
>               else
>                  throw ambiguous name
>               }

See above.

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

#6388

On 6/21/2011 8:54 PM, Peter Duniho wrote:
> On 6/21/11 4:37 PM, Gene Wirchenko wrote:
>> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
>> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>>
>> [snip]
>>
>>> Speaking of "shoddy", some might consider it "shoddy" to call the
>>> _operating system_ "case-insensitive" when in fact it's the _file
>>> system_ that is case-insensitive.
>>
>> Please do not nitpick.
>
> I have been known to nitpick, but making a distinction between operating
> system and file system is far from that.

That is true.

But it is not correct in the sense of being complete that it is the
file system that is case insensitive.

It is the file system and the command interpreter (shell in
*nix terminology).

Not all command are actual executables.

Arne

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

#6389

On 7/21/11 5:58 PM, Arne Vajhøj wrote:
> [...]
>> I have been known to nitpick, but making a distinction between operating
>> system and file system is far from that.
>
> That is true.
>
> But it is not correct in the sense of being complete that it is the
> file system that is case insensitive.
>
> It is the file system and the command interpreter (shell in
> *nix terminology).

Huh?  Inasmuch as the file system can be accessed, and case-sensitivity 
observed, without a command interpreter, I don't see why you are 
dragging the command interpreter into it.

There are lots of other things on a computer besides the file system 
that might or might not be case-sensitive, and you may even have trouble 
working with a case-sensitive file system if those things are not.  But 
I don't see how that's relevant here, where it's the case-sensitivity of 
the file system that is at issue.

Pete

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

#6419

On 7/21/2011 9:14 PM, Peter Duniho wrote:
> On 7/21/11 5:58 PM, Arne Vajhøj wrote:
>> [...]
>>> I have been known to nitpick, but making a distinction between operating
>>> system and file system is far from that.
>>
>> That is true.
>>
>> But it is not correct in the sense of being complete that it is the
>> file system that is case insensitive.
>>
>> It is the file system and the command interpreter (shell in
>> *nix terminology).
>
> Huh? Inasmuch as the file system can be accessed, and case-sensitivity
> observed, without a command interpreter, I don't see why you are
> dragging the command interpreter into it.
>
> There are lots of other things on a computer besides the file system
> that might or might not be case-sensitive, and you may even have trouble
> working with a case-sensitive file system if those things are not. But I
> don't see how that's relevant here, where it's the case-sensitivity of
> the file system that is at issue.

The topic is the original posters expectation of case insensitivity
of commands because of the OS (Windows) being case insensitive.

That has a lot to with the command interpreter.

Arne

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

#6440

On 7/22/11 2:19 PM, Arne Vajhøj wrote:
> The topic is the original posters expectation of case insensitivity
> of commands because of the OS (Windows) being case insensitive.
>
> That has a lot to with the command interpreter.

Since a different command interpreter, or a complete lack of one, would 
not have changed the behavior the OP was complaining about, I really 
don't see how.

But if you want to keep talking about the command interpreter, please 
feel free to do so.  Fine by me.

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

#6441

On 7/22/2011 10:45 PM, Peter Duniho wrote:
> On 7/22/11 2:19 PM, Arne Vajhøj wrote:
>> The topic is the original posters expectation of case insensitivity
>> of commands because of the OS (Windows) being case insensitive.
>>
>> That has a lot to with the command interpreter.
>
> Since a different command interpreter, or a complete lack of one, would
> not have changed the behavior the OP was complaining about, I really
> don't see how.

It has lot to do with peoples expectations.

And the problem was not in the file system either, so why did you bring
that up when you have that view on what is relevant?

Arne

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

#6442

On 7/22/11 8:17 PM, Arne Vajhøj wrote:
> [...]
> And the problem was not in the file system either, so why did you bring
> that up when you have that view on what is relevant?

I didn't "bring it up".  I was simply responding to the claim that the 
OS was case-insensitive (which it's not).

Inasmuch as there's a "problem" at all, I'd say it's "in the file 
system".  That is, the file system is not using the same rules as Java 
to identify the object.  Of course, it's not really a problem.  It's 
just the way it is.  But the file system is at least involved in the issue.

In any case, I'm sure you'd be happy to go back and forth all day on the 
topic, but I've explained myself as much as I care to.  I don't see why 
you felt a need to comment on my post, especially a full month after it 
was made, but if you think there's still more to be said, please feel 
free to carry on without me.

Pete

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

#6443

On 7/22/2011 11:25 PM, Peter Duniho wrote:
> On 7/22/11 8:17 PM, Arne Vajhøj wrote:
>> [...]
>> And the problem was not in the file system either, so why did you bring
>> that up when you have that view on what is relevant?
>
> I didn't "bring it up". I was simply responding to the claim that the OS
> was case-insensitive (which it's not).

That was not very good. It is some part of the OS that er
case insensitive.

But claiming that it is the file system is just as bad. Because
there are other parts that are also case insensitive.

> Inasmuch as there's a "problem" at all, I'd say it's "in the file
> system". That is, the file system is not using the same rules as Java to
> identify the object. Of course, it's not really a problem. It's just the
> way it is. But the file system is at least involved in the issue.

No file system will fix the problem.

Different file systems just result in different exceptions.

I am pretty sure that OP would not have been much happier with
the other exception.

> In any case, I'm sure you'd be happy to go back and forth all day on the
> topic, but I've explained myself as much as I care to. I don't see why
> you felt a need to comment on my post, especially a full month after it
> was made, but if you think there's still more to be said, please feel
> free to carry on without me.

It could be the same reason that you commented on the OS being
case-insensitive.

It was simply totally misleading.

And since neither Java nor CMD nor Win32 NTFS changed during
that month, then that should not be a reason not to comment.

Arne

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

#6461

On Jul 22, 8:38 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 7/22/2011 11:25 PM, Peter Duniho wrote:
>
> > On 7/22/11 8:17 PM, Arne Vajhøj wrote:
> >> [...]
> >> And the problem was not in the file system either, so why did you bring
> >> that up when you have that view on what is relevant?
>
> > I didn't "bring it up". I was simply responding to the claim that the OS
> > was case-insensitive (which it's not).
>
> That was not very good. It is some part of the OS that er
> case insensitive.
>
> But claiming that it is the file system is just as bad. Because
> there are other parts that are also case insensitive.
>
> > Inasmuch as there's a "problem" at all, I'd say it's "in the file
> > system". That is, the file system is not using the same rules as Java to
> > identify the object. Of course, it's not really a problem. It's just the
> > way it is. But the file system is at least involved in the issue.
>
> No file system will fix the problem.
>
> Different file systems just result in different exceptions.
>
> I am pretty sure that OP would not have been much happier with
> the other exception.
>
> > In any case, I'm sure you'd be happy to go back and forth all day on the
> > topic, but I've explained myself as much as I care to. I don't see why
> > you felt a need to comment on my post, especially a full month after it
> > was made, but if you think there's still more to be said, please feel
> > free to carry on without me.
>
> It could be the same reason that you commented on the OS being
> case-insensitive.
>
> It was simply totally misleading.
>
> And since neither Java nor CMD nor Win32 NTFS changed during
> that month, then that should not be a reason not to comment.
>

Truth should neither go out of fashion nor have a statute of
limitations.  Not only the systems you mention, but Usenet haven't
gone away.  Usenet posts are permanent, and old for far, far longer
than they're new.  Some future reader will benefit from both your
comments for far, far longer than a month from now.  If there are
facts to add, it's never too late.

So you go right on ahead and comment whenever you deem it relevant.

--
Lew

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

#6528

On 22/07/2011 11:14 AM, Peter Duniho wrote:
>> It is the file system and the command interpreter (shell in
>> *nix terminology).
>
> Huh? Inasmuch as the file system can be accessed, and case-sensitivity
> observed, without a command interpreter, I don't see why you are
> dragging the command interpreter into it.

I have to agree with that. I can't see what the command interpreter has 
to do with this at all. The file system is case-sensitive so everything 
that uses it is as well, including the shells. And of course by default 
*everything* in a computer is case-sensitive unless specifically 
programmed otherwise.

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

#6531

Esmond Pitt <esmond.pitt@bigpond.com> wrote:
> On 22/07/2011 11:14 AM, Peter Duniho wrote:
>>> It is the file system and the command interpreter (shell in
>>> *nix terminology).
>> Huh? Inasmuch as the file system can be accessed, and case-sensitivity
>> observed, without a command interpreter, I don't see why you are
>> dragging the command interpreter into it.
> I have to agree with that. I can't see what the command interpreter has 
> to do with this at all.

My guess would be, that for consistency it is preferable, that 
(CLI) shells follow the system's typical case in- or sensitivity 
even for its internal commands:
      cmd.exe:        cd, cD, Cd or CD
      *nix shells:    only cd
Still, just a marginal relation.

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

#5525

On Jun 21, 4:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
>
> <NpOeStPe...@NnOwSlPiAnMk.com> wrote:
>
> [snip]
>
> >Speaking of "shoddy", some might consider it "shoddy" to call the
> >_operating system_ "case-insensitive" when in fact it's the _file
> >system_ that is case-insensitive.
>
>      Please do not nitpick.
>

That's not nitpicking, and success in engineering comes from attention
to detail.

It is a meaningful difference, file system vs. OS itself, therefore
not nitpicking.  ALso, simply slapping a pejorative label like
"nitpicking" on a proposition doesn't make the proposition false or
even unimportant.

If you're going to call this "nitpicking", you need to support the
evaluation with evidence and reasoning.  Unfortunately, the point is
both valid and important, so you won't be able to support calling it
"nitpicking".

> [snip]

--
Lew

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

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

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

csiph-web