Re: Why does ls command sometimes case sensitively misbehave?

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Thu, 15 Aug 2002, Igor Pechtchanski wrote:

> On Thu, 15 Aug 2002, Geoffrey Scheller wrote:
>
> > >>>On Thu, 15 Aug 2002, Geoffrey Scheller wrote:
> > >>>
> > >>>> Why is ls doing this?  Other commands, like vi, also show
> > >>>> this behavior:
> > >>>>
> > >>>>     $ touch foo
> > >>>>
> > >>>>     $ ls
> > >>>>     foo
> > >>>>
> > >>>>     $ ls foo
> > >>>>     foo
> > >>>>
> > >>>>     $ ls FoO
> > >>>>     FoO
> > >>>>
> > >>>>     $ ls fo*
> > >>>>     foo
> > >>>>
> > >>>>     $ ls Fo*
> > >>>>     ls: Fo*: No such file or directory
> > >>>>
> > >>>> $ bash --version
> > >>>> GNU bash, version 2.05b.0(2)-release (i686-pc-cygwin)
> > >>>> Copyright (C) 2002 Free Software Foundation, Inc.
> > >>>>
> > >>>> Cygwin DLL version 1.3.12-2
> > >>>>
> > >>>> I run Cygwin on Windows XP Professional.
> > >>>>
> > >>>> Thanks,
> > >>>> Geoffrey
> > >>>
> > >>>What you're seeing is the behavior of the shell's filename globbing, not
> > >>>of ls or vi.  What is the value of your CYGWIN environment variable? Does
> > >>>it contain "check_case:<smth>"?  Does it contain "glob" or "noglob"
> > >>>(although that, IIRC, is only for command shell windows)?  What are the
> > >>>options of bash itself (`set | grep SHELLOPTS`)?
> > >>>    Igor
> > >>
> > >> $ shopt nocaseglob
> > >> nocaseglob      off
> > >>
> > >> At first that is what I thought, but
> > >>
> > >>     $ ls
> > >>     foo
> > >>
> > >>     $ ls 'Foo'
> > >>     Foo
> > >>
> > >> I think shell globbing is OK.
> > >>
> > >>     $ echo 'FoO' fo* FoO*
> > >>     FoO foo FoO*
> > >>
> > >> Problem still there whether or not I have turned on case sensitive globbing.
> > >>     $ shopt -s nocaseglob
> > >>
> > >>     $ echo 'FoO' fo* FoO*
> > >>     FoO foo foo
> > >>
> > >>     $ ls FoO
> > >>     FoO
> > >>
> > >> I think it is a little bit subtler.
> > >>
> > >> Geoffrey
> > >
> > >Did you try it under other shells (sh, ksh, tcsh)?  Did you try it under
> > >the command prompt?  And what is the value of your CYGWIN environment
> > >variable?  I think you might have a "check_case:adjust" in there...
> > >       Igor
> >
> >     $ set | grep SHELLOPTS
> >     SHELLOPTS=braceexpand:hashall:histexpand:interactive-comments:monito
> >
> > Also, CYGWIN environment variable not defined (Sorry I missed this on
> > previous thread).
> >     $env | grep CYGWIN
> >
> > Same behavior under sh and tcsh.  Don't have ash or ksh installed.  Also
> > same behavior when under command.com:
> >
> >     $ C:\CYGWIN\HOME\GEOFFREY\TEST>\cygwin\bin\ls FoO
> >     FoO
> >
> > Actually dir gets the name right.  (First time I ever saw dir do something
> > better than ls)
> >
> >     C:\cygwin\home\Geoffrey\Test>dir FoO
> >     Volume in drive C has no label
> >     Volume Serial Number is 3C08-4BE4
> >
> >     Directory of C:\cygwin\home\Geoffrey\Test
> >
> >     08/15/2002  06:35 PM                 0 foo
> >                1 File(s)              0 bytes
> >                0 Dir(s)   4,451,311,616 bytes free
> >
> > This is not a show stopper, but is irksome if I have a C and C++ by the same
> > name like bar.c and bar.C.  Thanks for your help.
> >
> > What is the behavior on other peoples Cygwin systems?
> >
> > Geoffrey
>
> First off, Windows systems are generally case-insensitive, and thus the
> files bar.c and bar.C would be considered the same file.  Unless you've
> turned off filename case insensitivity (and I don't remember how to do it,
> but there was a thread in the archives to that regard, with something
> about POSIX compliance, IIRC), the two names will clash, and
>
> # echo 'lowercase' >bar.c
> # echo 'uppercase' >bar.C
>
> will produce one file with 'uppercase' in it (not sure about the name, I
> think lowercase, but that's easily verifiable).
>
> Secondly, if you want more control over how filenames are treated, set
> the check_case option in your CYGWIN environment variable.  The detailed
> description is in the cygwin user's guide.
>         Igor
> P.S. I usually set mine to check_case:strict precisely because I have a
> case-insensitive file system.  This prevents writing to bar.C if bar.c
> exists, or opening bar.c as bar.C, but doesn't allow you to have both
> simultaneously (see above).

Actually, it looks like the value of check_case in $CYGWIN doesn't affect
the behavior of ls.  The underlying filesystem does.  What ls does is
stat() the file it's trying to open for permissions.  If stat() succeeds
(i.e. the file exists), ls will print it in the form the name was given to
it.  Since the underlying filesystem is case-insensitive, stat() will
succeed even for a name with the wrong case, and ls will happily print it.
Other tools that use this technique (vi being one) will behave similarly.
If you try to write the file from vi, however, the case should reflect the
original name, not the one given to vi (unless you force it to recreate
the file)...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

It took the computational power of three Commodore 64s to fly to the moon.
It takes a 486 to run Windows 95.  Something is wrong here. -- SC sig file


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/