RE: zsh - new user with questions

RE: zsh - new user with questions

[Stephen Riehm]

> 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
This is exactly what I'm talking about!

Steve

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.

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

Re: zsh - new user with questions

[Stephen Riehm]

Hi Again,



firstly, thanks to all those who replied, some of the tips were exactly
what I was looking for.



The expand-or-complete-prefix tip however didn't work, as then the -list
function only works when you've

already typed something. ie:



     cd /usr/<tab>



doesn't complete, and doesn't produce a list - ( I don't like using the
menu stuff, by the time I've hit tab 50 times

I could have easily typed any name I might be searching for), first when
you type another character does it start

showing lists again, ie:



     cd /usr/l<tab>

     lib/ local/



The way I work at the moment, I used the expand-or-complete-or-list
functionality instead of

having to use 'ls' all the time - which works great with case-insensitive
completion and list-when-ambiguous.

(ie: I often provide support by phone, they tell me to cd to
/home/user/Dev/ProductTest-1.2 - spoken as

slash home user dev product test one point two. I'm sure you can see where
case insensitivity and list-when-ambiguous

comes in really handy here. in tcsh I'ld probably type
/home/user/dev<tab>prod.2<tab> and I'ld be there, or if there

was an ambiguity, I'ld imediately see what choices I had.)

I'm not really complaining, I just find these features extremely helpful,
and I miss them a lot :-)



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)



Thanks again,



Steve

Re: zsh - new user with questions

[Goran Larsson]

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

[Bart Schaefer]

On Aug 19,  2:34pm, Stephen Riehm wrote:
} Subject: Re: zsh - new user with questions
}
} firstly, thanks to all those who replied, some of the tips were
} exactly what I was looking for.
}
} The expand-or-complete-prefix tip however didn't work, as then the
} -list function only works when you've already typed something. ie:
}
}      cd /usr/<tab>
}
} doesn't complete, and doesn't produce a list

Try adding

	setopt listambiguous autolist

which are defaults in 3.1.4.  (You probably have listambiguous already.)
With those options set, I see a listing upon typing cd /usr/<TAB>.

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

zsh - new user with questions

[Stephen Riehm]

Hi guys,



I know - first read the FAQ, then the man pages - done that and more and
I've still got the following questions:

(background: I'm a tcsh power-user - but due to politically induced
technical problems, I'm looking for something

more ksh compatible, but which can do a whole lot more - zsh)



     - extended completion. I'm terribly used to never having to type
UPPERCASE letters, and using

     extreme short cuts. ie: with tcsh's enhanced completions, to complete
the file named: ReadMe.First

     all I would type id: r.f<tab> - is there a way to do this sort of
thing in zsh?



     - I tried use ls ***/*(/l2) to find all the empty directories in a
tree, but it didn't work, instead it counted the number

     of directories in each directory (I think, I wasn't quite sure what it
was doing)



     - if you cd through a link, the prompt correctly knows where you are
logically, but cd'ing back up again

     with cd .. puts you in the directory above the physical directory in
which you were. Is it possible to make

     all cd's happen in relation to your logical position?



     - raw completions: the completion mechanism is quite nice, even if I
haven't totally groked it yet, but

     occaisonally I want to perform completions which are normally
disallowed by compctl. The simplest example is

     cd. "compctl -g '*(-/)' cd" will complete nicely, unless I want to cd
into a hidden (dot) directory. Then it doesn't

     complete at all. Is it possible to say that it should complete
non-hidden directories, unless the text typed indicates

     otherwise, ie: if I type "cd <tab>", I get a list of all the normal
directories, but if I then type .<tab> it should use the

     . and show me all the directories beginning with .



I've got lots of other questions, but they aren't as annoying as the ones
above. HAve any of you done anything in this direction

before?



Thanks in advance,



Steve

Re: zsh - new user with questions

[Matthew Lovell]

On 18 August 1998, Stephen Riehm writes:
 > 
 >      occaisonally I want to perform completions which are normally
 > disallowed by compctl. The simplest example is
 > 
 >      cd. "compctl -g '*(-/)' cd" will complete nicely, unless I want to cd
 > into a hidden (dot) directory. Then it doesn't
 > 
 >      complete at all. Is it possible to say that it should complete
 > non-hidden directories, unless the text typed indicates
 > 
 >      otherwise, ie: if I type "cd <tab>", I get a list of all the normal
 > directories, but if I then type .<tab> it should use the
 > 
 >      . and show me all the directories beginning with .


The following works nicely for me, with the behavior you desired:

# cd/pushd/rmdir only directories or symbolic links to directories.  If 
# none of those match, resort to shell variables
compctl -g '*(-/)' + -g '.*(-/)' -v cd pushd rmdir   

-- 

Matthew Lovell                       voice: (970) 898-6264 
Hewlett-Packard FSL                    fax: (970) 898-2510 
3404 E. Harmony Rd. MS A0         location: 3UR4
Fort Collins, CO 80528-9599         mailto:lovell@fc.hp.com

Re: zsh - new user with questions

[Peter Stephenson]

"Stephen Riehm" wrote:
>      extreme short cuts. ie: with tcsh's enhanced completions, to complete
> the file named: ReadMe.First
>      all I would type id: r.f<tab> - is there a way to do this sort of
> thing in zsh?

You can write your own function.  See Functions/multicomp in the
source distribution for examples.  If you really can't type uppercase
characters, you're going to have to redo the globbing there so
that every lowercase character becomes e.g. [rR], then you'll
need to handle .'s in the way /'s are handled there.  Ignoring case
may happen one day, but I doubt there's ever going to be a built-in
way of saying 'look and see if there are any characters preceeding a
dot to be added earlier on in the completion'.  Maybe you would be
interested in the options automenu and menucomplete.  You'll have
to find the shift key, however.  Do 'setopt automenu', type R,
and hit tab until it works.

>      - I tried use ls ***/*(/l2) to find all the empty directories in a
> tree, but it didn't work, instead it counted the number
>      of directories in each directory (I think, I wasn't quite sure what it
> was doing)

You need ls -d, and it doesn't just show empty directories since the link
count doesn't get incremented for plain files.  I don't think you
can do it in one glob expression.  Best I can think of (using your
glob to prune out non-terminal directories) is

for f in ***/*(/l2); do foo=($f/*(N)); [[ -z $foo ]] && print $f; done

*(N) turns on nullglob, i.e. $foo is empty if there was nothing in $f.

> Is it possible to make
>      all cd's happen in relation to your logical position?

This should happen with the option CHASE_LINKS unset.

> Is it possible to say that it should complete
> non-hidden directories, unless the text typed indicates
>      otherwise, ie: if I type "cd <tab>", I get a list of all the normal
> directories, but if I then type .<tab> it should use the
>      . and show me all the directories beginning with .

With 3.1.4, -/ is a better way of doing it than -g; this will work as you
want.  For more general things like that, you probably need to wait
until particular completions can be bound to particular keys, which
should happen some time.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: zsh - new user with questions

[David Hedbor]

Peter Stephenson <pws@ifh.de> writes:

> need to handle .'s in the way /'s are handled there.  Ignoring case
> may happen one day, but I doubt there's ever going to be a built-in
> way of saying 'look and see if there are any characters preceeding a
> dot to be added earlier on in the completion'.  Maybe you would be
> interested in the options automenu and menucomplete.  You'll have
> to find the shift key, however.  Do 'setopt automenu', type R,
> and hit tab until it works.

I am having similar problems, but with /. Example with bash (^ denotes 
the location of the cursor):

bash-2.01$ ls /usr/loc/bi
                      ^        
Pressing tab gives:

bash-2.01$ ls /usr/local/bi
                        ^
With zsh:

ls /usr/loc/bi           => beep
           ^
ls /usr/loc/bin          => /usr/local/bin/
           ^                          ^
ls /usr/loc/bin/         => /usr/local/bin//

           ^                          ^

So problem one is that local is not expanded if the path segment after 
it doesn't exist. The second problem is that zsh adds a "/" at the end 
of the path - always. I'd prefer if it didn't add one at all or at
least just one (the infinite number of added slashes is clearly a
bug).

The third problem is something that often bites me hard:

bash: ls /usr/lobin	=> /usr/local/bin
		^	       		
bash: ls /usr/lobin	=> beep
		^	       		
Ie zsh can't complete the path if the cursor is not on a slash. It
would be really nice if it completed from the character it was on,
even if it's not a slash.

This it he last "grudge" I have against zsh since switching from bash.

-- 
David Hedbor

Re: zsh - new user with questions

[Bart Schaefer]

On Aug 18,  3:46pm, David Hedbor wrote:
> Subject: Re: zsh - new user with questions
> Peter Stephenson <pws@ifh.de> writes:
> 
> bash-2.01$ ls /usr/loc/bi
>                       ^        
> bash-2.01$ ls /usr/local/bi
>                         ^
> With zsh:
> 
> ls /usr/loc/bi           => beep
>            ^
> ls /usr/loc/bin          => /usr/local/bin/
>            ^                          ^
> So problem one is that local is not expanded if the path segment after 
> it doesn't exist.

Try the following:

unsetopt completeinword
bindkey \^I expand-or-complete-prefix

Those settings will produce the effect you describe.  However, you may find
other differences from bash; I don't think there's any combinations of zsh
completion settings that exactly duplicate it.

You might also try setting up Functions/multicomp for extensive embedded
directory name completion.

> ls /usr/loc/bin/         => /usr/local/bin//
>            ^                          ^
> The second problem is that zsh adds a "/" at the end 
> of the path - always. I'd prefer if it didn't add one at all or at
> least just one (the infinite number of added slashes is clearly a
> bug).

I don't see that behavior, but I'm running a much-patched zsh.  What version
are you using?

> The third problem is something that often bites me hard:
> 
> bash: ls /usr/lobin	=> /usr/local/bin
> 		^	       		
> bash: ls /usr/lobin	=> beep
> 		^	       		
> Ie zsh can't complete the path if the cursor is not on a slash.

The expand-or-complete-prefix binding will take care of that, too.

Re: zsh - new user with questions

[Zefram]

Stephen Riehm wrote:
>     - extended completion. I'm terribly used to never having to type
>UPPERCASE letters, and using
>
>     extreme short cuts. ie: with tcsh's enhanced completions, to complete
>the file named: ReadMe.First
>
>     all I would type id: r.f<tab> - is there a way to do this sort of
>thing in zsh?

You can do these things with a completion function.  Look at `multicomp'
in the zsh distribution.

>     - I tried use ls ***/*(/l2) to find all the empty directories in a
>tree, but it didn't work, instead it counted the number
>
>     of directories in each directory (I think, I wasn't quite sure what it
>was doing)

You probably want "ls -d" or "echo" or something like that.  Plain "ls"
will list the *contents* of directories listed on the command line.

>     occaisonally I want to perform completions which are normally
>disallowed by compctl. The simplest example is
>     cd. "compctl -g '*(-/)' cd" will complete nicely, unless I want to cd
>into a hidden (dot) directory. Then it doesn't
>     complete at all. Is it possible to say that it should complete
>non-hidden directories, unless the text typed indicates
>     otherwise, ie: if I type "cd <tab>", I get a list of all the normal
>directories, but if I then type .<tab> it should use the
>     . and show me all the directories beginning with .

compctl -/ cd

-zefram