Re: CLI Java Glitch

Discussion in 'Java' started by Martin Gregorie, Jun 20, 2011.

  1. 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 |
     
    Martin Gregorie, Jun 20, 2011
    #1
    1. Advertising

  2. Martin Gregorie

    Esmond Pitt Guest

    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.
     
    Esmond Pitt, Jun 21, 2011
    #2
    1. Advertising

  3. Martin Gregorie

    Tom Anderson Guest

    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
     
    Tom Anderson, Jun 21, 2011
    #3
  4. Martin Gregorie

    Tom Anderson Guest

    On Mon, 20 Jun 2011, Martin Gregorie wrote:

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


    Ahem. The UNIX-family MacOS X - possibly only when using HFS+ and FAT,
    although i'm not sure - does case-wobbly comparisons. Case is preserved,
    but i think it is ignored when paths are looked up. It's been a while
    since i worked on OS X, so i forget the details.

    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
     
    Tom Anderson, Jun 21, 2011
    #4
  5. On Tue, 21 Jun 2011 22:49:59 +0100, Tom Anderson
    <> wrote:

    [snip]

    >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.


    OP here. Not on my system.

    >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.


    But that is about what happened!

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 22, 2011
    #5
  6. On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
    <> 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
     
    Gene Wirchenko, Jun 22, 2011
    #6
  7. Martin Gregorie

    Stefan Ram Guest

    Peter Duniho <> writes:
    >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 :) ).


    One could do something like this by wrapping every class file
    into a jar file.
     
    Stefan Ram, Jun 22, 2011
    #7
  8. Martin Gregorie

    Nigel Wade Guest

    On 21/06/11 22:49, 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.



    Does it? What different thing does it do?

    As far as a case-insensitive OS/filesystem is concerned, they would all
    appear as the same file. If Java asked for any of those names from the
    filesystem it would get the one file which did exist for any of the
    class names. It would then look in that file for the class it required.
    If the class did not exist in that file it would throw the
    ClassNotFoundException. It cannot do anything else because the
    OS/filesystem simply will not allow it.

    Java actually throws ClassNotFoundException in all cases, on all OS,
    just as it should. The only difference is that in a case-insensitive
    filesystem Java actually opens the case-insensitive filename before it
    discovers that it does not contain the class required. On case-sensitive
    filesystems the correct case filename won't be found. The actual result
    is the same in both cases, a ClassNotFoundException.

    >
    > 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
    >


    But Java cannot do this. On a case-insensitve OS/filesystem it simply
    may not be possible for a file to exist called HelloWorld.class.

    Java is not doing anything wrong. The user is, in assuming that because
    the OS/filesystem is case-insensitive that Java is also. The java
    command syntax is "java <ClassName>" not "java <filename>". That class
    name is case sensitive, no matter how brain dead the OS or filesystem.
    If you ask Java to run the class helloworld when your class is actually
    HelloWorld, you have asked it to do the wrong thing. Java is perfectly
    correct in telling you this.

    If you ask Java to run the class HelloWorld, it does so even on a
    case-insensitive system such as that of the OP. Even if the file is
    called helloworld.class Java still manages to do the right thing.
     
    Nigel Wade, Jun 22, 2011
    #8
  9. Martin Gregorie

    lewbloch Guest

    On Jun 21, 4:37 pm, Gene Wirchenko <> wrote:
    > On Tue, 21 Jun 2011 15:11:41 -0700, Peter Duniho
    >
    > <> 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
     
    lewbloch, Jun 22, 2011
    #9
  10. On 6/21/2011 3:11 PM, Peter Duniho wrote:
    > 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 :) ).


    You can do that, if you write your own custom class loader.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 22, 2011
    #10
  11. On Wed, 22 Jun 2011 09:02:25 -0700 (PDT), lewbloch
    <> wrote:

    [snip]

    >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".


    Sure, I can. It was quite clear what was being referred to. The
    pedanticism was unnecessary; there was no real danger of confusion.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 22, 2011
    #11
  12. On Wed, 22 Jun 2011 11:54:02 +0100, Nigel Wade <>
    wrote:

    [snip]

    >Java is not doing anything wrong. The user is, in assuming that because


    It is apparently acting per spec, but the spec is overly fussy
    (IMO).

    >the OS/filesystem is case-insensitive that Java is also. The java
    >command syntax is "java <ClassName>" not "java <filename>". That class
    >name is case sensitive, no matter how brain dead the OS or filesystem.
    >If you ask Java to run the class helloworld when your class is actually
    >HelloWorld, you have asked it to do the wrong thing. Java is perfectly
    >correct in telling you this.


    And I, as the end user, am perfectly correct in calling this a
    quality of implementation issue regarding user-friendliness.

    Being perfectly correct is not good enough when playing with
    others who may well have other priorities. When a program and a user
    conflict over interface issues, I think that the user should be the
    one to prevail.

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 22, 2011
    #12
  13. On 6/22/2011 10:12 AM, Gene Wirchenko wrote:
    > On Wed, 22 Jun 2011 09:02:25 -0700 (PDT), lewbloch
    > <> wrote:
    >> 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".

    >
    > Sure, I can. It was quite clear what was being referred to. The
    > pedanticism was unnecessary; there was no real danger of confusion.


    Not really. The operating system performs a lot of actions that deal
    with strings. If the operating system itself were case insensitive,
    there would be no distinction between `a' and `A' pretty much anywhere
    in the entire stack. Instead, the only limitation here is that the
    filesystem will happily return a file named `A.txt' when you asked for
    `a.txt'. If you really want to get pedantic, note that the filesystem
    knows the difference between `A.txt' and `a.txt' (i.e., it can preserve
    case). It just chooses to treat them as equivalent for the purposes of
    stat'ing the file.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 22, 2011
    #13
  14. Martin Gregorie

    Tom Anderson Guest

    On Tue, 21 Jun 2011, Peter Duniho wrote:

    > 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.


    It would certainly have been better to say file system rather than
    operating system, i agree. However, the file system is part of the
    operating system. If the operating system's file system is
    case-insensitive when dealing with file paths, then the operating system
    is case-insensitive when dealing with file paths. I don't think my
    phrasing is incorrect.

    Where my precision did lapse was in saying "a case-insensitive operating
    system" rather than "an operating system which is case-insensitive when
    dealing with file paths". You're quite right that this means something
    much broader - even when applied to just the file system, where you might
    or might not have case sensitivity around device IDs, disk labels, user
    names, etc.

    >> 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.


    Er, yes. I am suggesting that Java *pretend* that it came from the
    operating system. That it treat "asked for foo.class, got Foo.class" the
    same as "asked for foo.class, it wasn't found".

    > 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.


    If the OS has a system call to retrieve the name of a file attached to an
    open file descriptor, and that returns the name in the case with which it
    was created, then it can easily do better - after opening the file, it
    could check that it's really the file it asked for. I believe Windows has
    such a call (or calls - it's a bit messy):

    http://stackoverflow.com/questions/65170/how-to-get-name-associated-with-open-handle

    If the OS doesn't have such a call, then it can still be done, by
    determining the directory name of the path, listing that directory, and
    looking for a case-sensitive match for the filename. This is rather more
    dubious, because it could get slow in very large directories.

    tom

    --
    It is a formal cultural policy to show unreasonable bias towards any
    woman who is both attractive and weird.
     
    Tom Anderson, Jun 22, 2011
    #14
  15. On Wed, 22 Jun 2011 11:06:38 -0700, Patricia Shanahan <>
    wrote:

    >On 6/22/2011 10:16 AM, Gene Wirchenko wrote:
    >...
    >> Being perfectly correct is not good enough when playing with
    >> others who may well have other priorities. When a program and a user
    >> conflict over interface issues, I think that the user should be the
    >> one to prevail.

    >
    >When dealing with a single-user program that makes sense.
    >
    >Of course, javac and java are both used by many users. How do you
    >propose to let "the user" be the one to prevail, when there are
    >thousands of users with different backgrounds and interface expectations?


    Easy on this point. Accepting case-insensitive filenames as
    matching when there is no ambiguity is more helpful to more users than
    throwing an error is.

    While I am at it, I find the Java error for not finding a program
    to be rather verbose for little use. It does not inform much more
    than
    Bad command or filename.
    or
    'q' is not recognized as an internal or external command,
    operable program or batch file.
    do.

    >I find the case insensitivity of MS-Windows file names very
    >counter-intuitive. Does that mean MS-Windows should be changed so that
    >Patricia-as-the-user can prevail?


    Maybe it should. But even if I did not agree, I would not argue
    against your expectations by calling them wrong.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 22, 2011
    #15
  16. Martin Gregorie

    Tom Anderson Guest

    On Wed, 22 Jun 2011, Nigel Wade wrote:

    > On 21/06/11 22:49, 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.

    >
    > Does it? What different thing does it do?


    To clarify, i meant that it does different things in these three
    situations:

    (1) helloworld exists
    (2) HelloWorld, hElLoWoRlD, HelloworlD, or similar exists
    (3) no class case-insensitively called helloworld exists

    I think that cases (2) and (3) should do the same thing. Or, as you
    describe it:

    > Java actually throws ClassNotFoundException in all cases, on all OS,
    > just as it should. The only difference is that in a case-insensitive
    > filesystem Java actually opens the case-insensitive filename before it
    > discovers that it does not contain the class required. On case-sensitive
    > filesystems the correct case filename won't be found. The actual result
    > is the same in both cases, a ClassNotFoundException.


    Now, this is where i think i've gone wrong. Back when i used Windows, java
    did *not* do the same thing in cases (2) and (3). For the nonexistent file
    in (3), it would throw a NoClassDefFoundError. But for the misnamed file
    in (2), it would throw something else - a ClassFormatError, i think.

    It seems that this has been fixed without me noticing, and i failed to
    interpret Gene's original post correctly. If this is the case, then i
    withdraw my complaint entirely!

    tom

    --
    It is a formal cultural policy to show unreasonable bias towards any
    woman who is both attractive and weird.
     
    Tom Anderson, Jun 22, 2011
    #16
  17. On 22 Jun 2011 19:45:02 GMT, -berlin.de (Stefan Ram)
    wrote:

    [snip]

    > Programmers usually are grateful to get error reports as
    > soon as possible.


    We are even more grateful not to have something flagged as an
    error when it is not, or when it need not be.

    > The most successful programming languages today are Java, C
    > and C++, all case-sensitive. There are case-insensitive
    > languages, but they are less successful. Implementations of
    > these successful and popular languages Java, C, and C++
    > actually throw error messages upon case errors.


    Correlation is not causation.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jun 22, 2011
    #17
  18. Martin Gregorie

    Paul Cager Guest

    On Jun 22, 7:46 pm, Gene Wirchenko <> wrote:
    > On Wed, 22 Jun 2011 11:06:38 -0700, Patricia Shanahan <>
    > wrote:
    > >Of course, javac and java are both used by many users. How do you
    > >propose to let "the user" be the one to prevail, when there are
    > >thousands of users with different backgrounds and interface expectations?

    >
    >      Easy on this point.  Accepting case-insensitive filenames as
    > matching when there is no ambiguity is more helpful to more users than
    > throwing an error is.


    My preference is to retain the current situation where the 'java'
    command consistently rejects a wrong classname. I prefer consistent
    behaviour over the ability to type the class name without pressing the
    shift key (in most cases).

    Your preference, I believe, is the opposite.

    I don't think either of us should present our personal preference as
    being "more helpful to more users" without being reasonably certain
    that we speak for the majority of users.
     
    Paul Cager, Jun 22, 2011
    #18
  19. Martin Gregorie

    Tom Anderson Guest

    On Wed, 22 Jun 2011, Stefan Ram wrote:

    > The word »Cuban« means »related to Cuba«,
    > while »cuban« means »related to cubes«.


    I don't believe it does - i've never heard that word before - but i will
    certainly use it to mean that in future.

    > When I made a case-related mistake in a dictation exercise
    > in school, the teacher marked that as an error and gave me a
    > worse grade, which in turn helped me to learn the language.


    Was this in English or German (or something else)? I don't know German,
    but i've been told that case is much more significant in German than in
    English.

    tom

    --
    drink beer and forget about gods. -- derslangerman
     
    Tom Anderson, Jun 22, 2011
    #19
  20. Martin Gregorie

    Stefan Ram Guest

    Tom Anderson <> writes:
    >>The word »Cuban« means »related to Cuba«,
    >>while »cuban« means »related to cubes«.

    >I don't believe it does - i've never heard that word before - but i will
    >certainly use it to mean that in future.


    http://mathworld.wolfram.com/CubanPrime.html
    http://en.wikipedia.org/wiki/Cuban_prime

    http://en.wikipedia.org/wiki/Cuban_hip_hop
    http://en.wikipedia.org/wiki/Cuban_Revolution

    http://en.wikipedia.org/wiki/Capitonym

    >>When I made a case-related mistake in a dictation exercise
    >>in school, the teacher marked that as an error and gave me a
    >>worse grade, which in turn helped me to learn the language.

    >Was this in English or German (or something else)?


    in German.

    >I don't know German, but i've been told that case is much
    >more significant in German than in English.


    There are more words beginning with an uppercase letter (I
    am thinking of nouns, which always begin with an uppercase
    letter), so one can find more examples of minimal pairs.

    OTOH, »I« is written in uppercase in English, while the
    corresponding German word is not.
     
    Stefan Ram, Jun 23, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Ram

    Re: CLI Java Glitch

    Stefan Ram, Jun 20, 2011, in forum: Java
    Replies:
    2
    Views:
    314
    Stefan Ram
    Jun 21, 2011
  2. Jeff Higgins

    Re: CLI Java Glitch

    Jeff Higgins, Jun 21, 2011, in forum: Java
    Replies:
    9
    Views:
    391
    Tom Anderson
    Jun 21, 2011
  3. Roedy Green

    Re: CLI Java Glitch

    Roedy Green, Jun 21, 2011, in forum: Java
    Replies:
    9
    Views:
    335
    Arne Vajhøj
    Jul 22, 2011
  4. Tom Anderson

    Re: CLI Java Glitch

    Tom Anderson, Jun 21, 2011, in forum: Java
    Replies:
    2
    Views:
    289
    Arne Vajhøj
    Jul 22, 2011
  5. Jeff Higgins

    Re: CLI Java Glitch

    Jeff Higgins, Jun 22, 2011, in forum: Java
    Replies:
    8
    Views:
    426
    Arne Vajhøj
    Jul 22, 2011
Loading...

Share This Page