Re: zsh - new user with questions

Re: zsh - new user with questions

[Stephen Riehm]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]




Hi Goran,

you make things more complicated than they are. In english there are also
numbers which
don't have an upper case equivalent. In those cases you represent those
characters as they
are, no one uses z to represent a lower case beta.

If you are familiar with the locale routines provided in the normal C
libraries, you'll know that
there are routines for converting strings from upper case to lower case and
vice-versa. These
routines are language independant, and only effect those characters which
have a upper/lower
case equivalent, all other characters in the string remain identical. (ever
seen an upper case space?)

All that is required is that all routines that compare file names need to
convert both strings for comparison
to lower (or upper) case before comparison. The advantage on the Amiga is
that if a file called ReadMe
exists, and you decide to create a file called README, all you end up doing
is overwriting the ReadMe file
(with the normal warnings you would get if you were to do that on any other
system)

The upshot is that you can be expressive with your file names, or you can
even be lazy, like the options
for zsh - setopt has even more magic, there you can user upper/lower case,
and you can insert underscores
anywhere you want - impressive! Maybe someone can use the same routine for
the expansion/completion stuff.
(ie: should not be restricted to files. variables, options, list entries
(compctl -k ...) etc should also be handled the
same way!

All the best, and thanks for listening,

Steve





hoh@lorelei.approve.se on 19.08.98 15:53:31

To:   Stephen Riehm/Muenchen/pc-plus
cc:   zsh-users@math.gatech.edu
Subject:  Re: zsh - new user with questions




[-- Attachment #2: Type: text/plain, Size: 1627 bytes --]



On 19 Aug, Stephen Riehm wrote:

>  If there's a wishlist or a todo list for zsh, I would really like to add
>  this feature to it! (I personally think the Amiga
>  dudes got it right back in '86 when they made the file names were only
>  stores case sensitive - but all operations
>  at OS level were case insensitive - thus it was impossible to have
ReadMe
>  and README in the same directory.
>
>  I personally think this reduces possible confusion, (does make read
>  Makefile or makefile first?) and makes
>  case insensitive completion trivial. - just my 2cents)

This is trivial if you only care about filenames using A..Z and a..z.
For filenames using other characters this must turn into a nightmare.
Some languages does not have a 1:1 mapping between upper and lower
case letters. One such example is the German "doube s" ß. Imagine
a language where 'z' does not have an upper case version and is
written as 'S' instead.

Set the language setting to English and create the file "Tezt".

   Filename on disk:    Tezt
   Open with:           Test (no)   Tezt (yes)   TEST (no)   TEZT (yes)

Change the language setting to the other language and try again.

   Filename on disk:    Tezt
   Open with:           Test (no)   Tezt (yes)   TEST (yes)  TEZT (what?)

Confusing? Confuzing?

How does Amiga handle this? How does MS win9[58] handle this?

Isn't it much easier to just say that upper and lower case are
distinct letters?

--
 Goran Larsson            hoh@approve.se
 I was an atheist,        http://home1.swipnet.se/%7Ew-12153/
 until I found out I was God.

Re: zsh - new user with questions

[Goran Larsson]

On 19 Aug, Stephen Riehm wrote:

>  are, no one uses z to represent a lower case beta.

Lower case beta? Who said anything about beta? I used a German
double s as an example. A German double s is not the same as beta.

>  If you are familiar with the locale routines provided in the normal C
>  libraries, you'll know that
>  there are routines for converting strings from upper case to lower case and
>  vice-versa. These
>  routines are language independant, and only effect those characters which
>  have a upper/lower
>  case equivalent, all other characters in the string remain identical.

These routines produce different results depending on the language
you have selected. If you use these routines to do filename matching
then you will match different filenames depending on the selected
language. This is what I think is confusing.

>  (ever seen an upper case space?)

Should ß be handled just like a space, that is, not changed at all?

>  All that is required is that all routines that compare file names need to
>  convert both strings for comparison
>  to lower (or upper) case before comparison. The advantage on the Amiga is
>  that if a file called ReadMe
>  exists, and you decide to create a file called README, all you end up doing
>  is overwriting the ReadMe file

You post from a .de domain so you should know about double s.
The upper case version of ß is SS.

1. If we have a filename with the name "Strasse" and one with the
   name "Straße". Both filenames are created when the English
   language is selected. If the German language is selected later,
   wich one of them should be accessed as "STRASSE"?

2. If we have a filename with the name "Straße" you can access it
   as "STRASSE" if you select German, but not if you select English.

Once more, how is the filename "Straße" handled on the Amiga? Don't
tell me they cheated and made the upper case version "STRAßE"!

Case insensitive filenames in an international environment is
quite a big can of worms. Should it be opened?

-- 
 Goran Larsson            hoh@approve.se
 I was an atheist,        http://home1.swipnet.se/%7Ew-12153/
 until I found out I was God.

Case insensitive completion (Re: zsh - new user with questions)

[Bart Schaefer]

On Aug 19,  5:09pm, Stephen Riehm wrote:
} Subject: Re: zsh - new user with questions
}
} All that is required is that all routines that compare file names need
} to convert both strings for comparison to lower (or upper) case before
} comparison.

Minor nit:  It can't be _all_ routines that compare file names, because
the files README ReadMe Readme readme and rEaDmE might all exist in the
same directory.  At some point you have to notice case to identify the
one you really mean.  Case-insenstive globbing is much more dangerous
than case-insensitive completion, particularly given multios (where e.g.
"echo foo > r*me" might clobber all five files).

In any case (pun intended), here's a bit of a hack to make the multicomp
function be case-insensitive in the ASCII set, including making `-' and
`_' interchangable.  It should be obvious how to add other mappings; for
example, to equate comma and period, append :gs/,/./:gs/./.,/

There might be a simpler way to achieve this, but short of using process
substitution I couldn't think of one.

Index: Functions/multicomp
===================================================================
--- multicomp	1998/06/01 17:08:43	1.1.1.1
+++ multicomp	1998/08/19 17:40:06
@@ -53,7 +53,17 @@
     else
       wild='*'
     fi
-    reply=(${sofar}"${head}${wild}${globdir}")
+
+    # Simulate case-insensitive globbing for ASCII characters
+    wild="[${(j(][))${(s())head:l}}]${wild}"	# :gs/a/[a]/ etc.
+    # The following could all be one expansion, but for readability:
+    wild=$wild:gs/a/aA/:gs/b/bB/:gs/c/cC/:gs/d/dD/:gs/e/eE/:gs/f/fF/
+    wild=$wild:gs/g/gG/:gs/h/hH/:gs/i/iI/:gs/j/jJ/:gs/k/kK/:gs/l/lL/
+    wild=$wild:gs/m/mM/:gs/n/nN/:gs/o/oO/:gs/p/pP/:gs/q/qQ/:gs/r/rR/
+    wild=$wild:gs/s/sS/:gs/t/tT/:gs/u/uU/:gs/v/vV/:gs/w/wW/:gs/x/xX/
+    wild=$wild:gs/y/yY/:gs/z/zZ/:gs/-/_/:gs/_/-_/
+
+    reply=(${sofar}"${wild}${globdir}")
     reply=(${~reply})
   fi
 

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh - new user with questions

[Bart Schaefer]

On Aug 19,  7:35pm, Goran Larsson wrote:
} Subject: Re: zsh - new user with questions
}
} 1. If we have a filename with the name "Strasse" and one with the
}    name "Straße". Both filenames are created when the English
}    language is selected. If the German language is selected later,
}    wich one of them should be accessed as "STRASSE"?
} 
} 2. If we have a filename with the name "Straße" you can access it
}    as "STRASSE" if you select German, but not if you select English.

He's not suggesting changing the behavior of the file system, he's
suggesting changing the behavior of completion.  That is, if in zsh
you typed

zsh% ls STRASSE<TAB>

then zsh would complete case-insensitively and you'd see

zsh% ls Straße
              ^
	      cursor here

The actual _access_ to the file still has to use its "real" name.

Now, it's a bit more difficult to deal with cases where two characters
maps onto one like that, because zsh normally assumes that completion
can only produce longer words ... but otherwise it's neither impossible
nor a problem for file creation or access.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh - new user with questions

[Roland Jesse]

Bart Schaefer wrote:

> The actual _access_ to the file still has to use its "real" name.

Now it's getting confusing. If the completion tells me a different file
name than the one acutally stored in the file system, I can easily imagine
cases in which I am not sure what the command, the completion is used for,
is going to do.

Regards,

	Roland

Re: Re: zsh - new user with questions

[Sweth Chandramouli]

On Wed, Aug 19, 1998 at 09:58:29PM +0200, Roland Jesse wrote:
> Bart Schaefer wrote:
> 
> > The actual _access_ to the file still has to use its "real" name.
> 
> Now it's getting confusing. If the completion tells me a different file
> name than the one acutally stored in the file system, I can easily imagine
> cases in which I am not sure what the command, the completion is used for,
> is going to do.
	
	but no one ever suggested that completion tell you a different name.  
what people have been discussing is completion _recognizing_ a different name, 
and completing it to the "correct" name.  basically, zsh would no longer look 
for exact matches when searching for possible completions, but would instead use 
some set of algorithms for the search.  in theory, i don't see why this would 
cause any problems, as bart shows in his example:
	
> zsh% ls STRASSE<TAB>
> 
> then zsh would complete case-insensitively and you'd see
> 
> zsh% ls Straße

	the completion tells you _exactly_ the file name that is stored in the 
system, despite your asking for the wrong one.  so long as the algorithms used 
were based on some standard translation (and so long as they were used just for 
completion--as someone else pointed out, using it for general globbing could be 
problematic), then the absolute worst result that could happen is that 
completion would, as it does now, simply not find the file for which you are 
searching--if i were using some different lang set, where ß was not considered 
the lowercase version of "SS", then the session would look like this:

zsh% ls STRASSE<TAB>
<beep>
zsh% ls STRASSE

	at which point i could slap my head, realize i was using the 
western-bulgarian charset, and try to figure out what the real spelling of the 
file was myself.
	
	(actually, that would be what would happen for iso_8859_1, in addition 
to western-bulgarian, which sees the uppercase version of ß as À (at least 
according to 

zsh% echo 'ß' | tr "[:lower:]" "[:upper:]"

	.  so, is there some easy way to view the character tables (and maybe 
even the ascii sequences that map to them) for a given language charset, from 
the command line?  how about to view the upper<->lower translation tables, or 
does it simply increment/decrement the ascii value by a certain amount and use 
whatever is returned by the new value?
	
	-- sweth.
	
-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

Re: Re: zsh - new user with questions

[Roland Jesse]

Sweth Chandramouli wrote:

> 	the completion tells you _exactly_ the file name that is stored in the 
> system, despite your asking for the wrong one.

Ok, I got it. Sorry for the noise.

	Roland

RE: zsh - new user with questions

[Andrej Borsenkow]

I normally use menu completion, and would expect it to be as following:

the list of possible matches is built case-insensitive (using whatever current locale says), but the choices are present as is. That is, giving readme, Readme and ReadMe, pressing "less rTAB" would list all three files as is. So, I would have full control over which file to select.

/Andrej

-----Original Message-----
From: Roland Jesse [mailto:jesse@prinz-atm.CS.Uni-Magdeburg.De]
Sent: Wednesday, August 19, 1998 11:58 PM
To: zsh-users@math.gatech.edu
Subject: Re: zsh - new user with questions


Bart Schaefer wrote:

> The actual _access_ to the file still has to use its "real" name.

Now it's getting confusing. If the completion tells me a different file
name than the one acutally stored in the file system, I can easily imagine
cases in which I am not sure what the command, the completion is used for,
is going to do.

Regards,

	Roland