Unidentified subject!

Unidentified subject!

[Je suis une creature de la Nuit]

susbcribe zombie@hare.utep.edu

Unidentified subject!

[Oliver Kiddle]

>From opk101 Sun Feb  1 14:37:39 1998
From: opk101@cs.york.ac.uk (Oliver Kiddle)
Date: Sun, 1 Feb 1998 14:37:39 +0000
In-Reply-To: borsenkow.msk@sni.de
       "Re: Completion on cd" (Feb  1, 12:53pm)
To: zsh-users@math.gatech.edu
Subject: Re: Completion on cd

On Feb 1, 12:53pm, borsenkow.msk@sni.de wrote:

> On Fri, 30 Jan 1998, Oliver Kiddle wrote:
> > % cd .netscape/[tab]
> >  -- All the *files* and directories in .netscape/ (not starting ".") are
> >  -- listed! I'd have expected it to complete to "cd .netscape/plugins/"

> I cannot reproduce it. compctl -/ cd correctly lists only directories,
> with or without . May be, it depends on some options settings; try zsh -f.

I ran zsh -f, put the cd compctl in and found the problem did not exist. 
I then added everything in my setup files a block at a time, checking
for the problem after each block so that I could try to determine where
the problem was being introduced.

I tracked the problem down to this line:

compctl -Tx 'C[0,*/*]' -f - 's[~]' -k users -S/ \
        - 'c[-1,-display]' -k hostnames -S':0 '

My first thought was that I had done something stupid when writing this
compctl but the troublesome part of it (the first line) was taken
directly from the Z Shell Guide (Edition 2.1.10, Chapter 18, Page 89 or
Edition 3.1.1, Chapter 19, Page 95)

There are a few thousand users at the university so I want this
completion to I attempted to find a better solution. My solution was
the following:

compctl -Tx 's[~] C[0,[^/]#]' -k users -S/

There may well be a problem with this though it seems to work and I
can't see any nasty suprises but I would strongly suggest that the
manual is changed so that nobody else has this problem. 

Note that the problem with cd ..[tab] beeping as opposed to completing
to cd ../ is still there.

Oliver Kiddle

PS Ignore my comment about the patch for the -Y option in my last
e-mail: when testing it I had forgotten that I was still running zsh
3.0.1 from an earlier test.


-- 
 __
/  \|.   _ _  |_/. _| _|| _     E-mail: opk101@cs.york.ac.uk
\__/||\/(-|   | \|(_|(_||(-        Web: http://www.york.ac.uk/~opk101/

Unidentified subject!

[Quinn Dunkan]

>>> A $LASTPID or something parameter, which is the pid of the last command run.
>>> Yes, I know about $!, but that only works if the process is &ed and not at all
>>> if it forks like a daemon (or maybe daemons pitchfork() ?).
>
> Don't let go of that tiger's tail.  He'll take you on a nice ride...

    Not really, he turned around and bit me pretty early on, right next to my
ctty and session-id tiger-bites.

>>> As much as I try, I can't figure out a good way to have zsh execute some
>>> command at startup and stay in interactive mode.
>
> Show us a shell in which you can, and we'll duplicate it. ;>

    If that had to be done for every zsh feature, I'd be using the other shell.
There may be a good reason no one else has done it, but I don't know it, and
no one has told it to me.  zsh should never hesitate to innovate (and with
modules, experimental features will be easy(er) to implement without annoying
all the conventionalists.

> >>      Also, is it better to stick vars in zlogin and export them so future
> >> shells inherit them, or put things like PATH, MANPATH, HOSTNAME, etc. in
> >> zshenv?
> >
> > Put them in zshenv, and export if appropriate.
> 
> Be sensible.  EDITOR, HISTFILE, HISTSIZE, LESS, PAGER, VISUAL, and other
> such environment variables shouldn't be in zshenv - they can only be
> used in interactive shells.  Of course, setting every environment
> variable I set takes less than a second; it doesn't hurt *that* much
> unless you have a *lot* of shell scripts that read /etc/zshenv.

    I didn't mention HISTFILE, HISTSIZE, etc., because I know those are usually
useful only for interactive sessions.  LESS, however, can certainly affect
things, I have a number of scripts which do the ${=PAGER:-less} thing.

> Question: would it be possible to avoid this whole problem by re-writing
> /sbin/init as a zsh script?  That way, it can export all of the variables,
> and so you don't need to worry about cron-executed programs having a
> different environment.

    That's an interesting idea.  Not for enviroment changes---I agree with
zefram that scripts should be independent of whatever zsh enviroment they
happen to be in---but because it would be sort of cool.  Let's see, you need to
muck with utmp/wtmp, catch signals, respawn things... nothing I can think of
that a shell script couldn't do.  Whether that's a good idea is another
matter... besides, my init exports a couple of env vars (INIT_VERSION, CONSOLE,
RUNLEVEL, and PREVLEVEL), and it's all destroyed by /bin/login anyway.

    With the perl thing, I think zsh modules should add new ways to interact
with zsh, not reproduce functionality that already exists in external programs.
I'm not sure why people are reproducing ls, cp, etc. as builtins, though.
The only advantage that I can think of a perl builtin would have over
perl -e '' at the command line would be keeping it's variables around.
Actually, it shouldn't be to hard to turn perl into a shell, it has an
autoloading feature you can use to tell it to try system() on functions it
can't find.  Just make the autoload function smart enough to parse pipes,
redirections, ampersands, and all that shellish stuff, and maybe make newline
acceptable for ;.  You'd have to change some more things, like having @path
instead of $path, and integrating %ENV and the normal %MAIN namespace.  We've
got our settor functions too :)  I'm not _extra_ crazy about programming in
perl, but I'm less crazy about programming in shell, and programming in perl
and shell at the same time would make me totally crazy.

    Meanwhile, while people _are_ writing builtins for cp, ls, etc, there's
part of our solution to the chase_links problem.  Also, I wonder what people
think of ``fake filesystems'', like .tar.gz and ftp ``directories''.  Of
course, this sort of thing is much better handled in the kernel (well, actually
much better handled by a user-mode filesystem server, but unix doesn't do
that), but as long as we're stuck with what we've got, it would be sort of
cool.  Of course, you'd need some extra zsh stuff, like directory cacheing, but
it seems fairly feasible, at least to me.  Desirable?  I dunno...

    BTW, what is the use of the > and < redirections?  It seems they could be
replaced with `re file | cmd' and `cmd | wr file' (read and write are already
taken).  It would be more to type, but the current distinction shells make
between pipes and redirections has always been strange to me.  Does the shell
really need a way to read and write directly to files?  It seems it would be
easier to replace this <, >,>&,#>&#, >>, etc. etc. syntax with | and #| (#|
piping fd # to a coprocess).  Then all that complex and messy redirection stuff
can be replaced by a simple external program (or builtin), so instead of
`cmd >>foo' you do `cmd | wr -a foo'. I'm just trying to stir things up here :)

    Well, this doesn't really have to do with zsh, but has anyone noticed where
pty (the program suite) went?  It doesn't seem to be as widespread as its
coolness warrants.  I couldn't find a linux port so I hacked my own.  I ask
because the author had a lot of interesting things to say about job control and
ttys, the sorts of things shell-developers would also know about.

Re: Unidentified subject!

[Zefram]

Uli Zappe wrote:
>I am porting a large and complex sh-script to zsh because I need  
>the ability of zsh to deal with German Umlauts. While after some  
>effort most everything works, I have encountered the following  
>strange problem:
[standard field splitting problem]

By default, zsh's behaviour is not completely compatible with sh.  If
you want to just run a sh script under zsh, put the command "emulate
sh" at the beginning of the script, and it should work.  If you'd
rather rewrite the script to do things the zsh way, you should use
arrays throughout for storing lists of filenames.

-zefram

Unidentified subject!

[Uli Zappe]

Hi,

first of all, I wrote:

>since I have a few questions concerning zsh somebody sent me the
>address of this mailing list but I don't know how to
>subscribe/unsubscribe (mechanisms differ widely...). Could a kind  
>soul please give me this info?

This mail has apparently already triggered the subscription  
mechanism by mentioning "subscribe" in the subject line, so no help  
is necessary anymore :-)

Now my problem which I find quite confusing:

I am porting a large and complex sh-script to zsh because I need  
the ability of zsh to deal with German Umlauts. While after some  
effort most everything works, I have encountered the following  
strange problem:

I have to create a list of file names to use it with 'cat' in a  
for-do loop:


   for VARIABLE in $VARIABLE_LIST
   do
      < generate the according filename FILE >
      FILENAME_LIST="$FILENAME_LIST$FILE "
   done


Now, if I do a 'echo $FILENAME_LIST' I get the wanted result

   FILE1 FILE2 FILE3...

However, if I then process

   cat $FILENAME_LIST

I get

   FILE1
   FILE2
   FILE3: No such file or directory

i.e obviously 'cat' treats all the files as a single filename; and  
this because the filenames for some strange reason are NO MORE  
separated by spaces but by newlines.

After endles tinkering I found out I can remedy this situation by doing a

   FILENAME_LIST=($(echo $FILENAME_LIST))

before applying FILENAME_LIST to cat; but that seems like a weird  
pseudo-tautological patch to me.


What confuses me most is the following:

If (just for test purposes) I define

   FILENAME_LIST=(FILE1 FILE2 FILE3)

instead of defining it by the for-do loop, everything works WITHOUT  
the need for the above mentioned patch. HOWEVER, if I do an 'echo  
$FILENAME_LIST' for debugging purposes in both cases, I get exactly  
the SAME OUTPUT IN BOTH CASES. I.e. though this 'echo  
$FILENAME_LIST' command displays

FILE1 FILE2 FILE3

in both cases without ANY difference, in one case 'cat  
$FILENAME_LIST' won't work and in the other case it will.



Can somebody please explain me what's going on?
And can you tell me if I REALLY have to use this strange patch from  
above, or if there's a "regular" solution to my problem?

Thank you VERY much for any insight!


                Bye
                        Uli

______________________________________________________________________

Uli Zappe               E-Mail: uli@tallowcross.uni-frankfurt.de
                                (NeXTMail,Mime,ASCII) PGP on request
Lorscher Strasse 5      WWW:    -
D-60489 Frankfurt       Fon:    +49 (69) 9784 0007
Germany                 Fax:    +49 (69) 9784 0042

staff member of NEXTTOYOU - the German NEXTSTEP/OPENSTEP magazine
______________________________________________________________________

Unidentified subject!

[compdsgn]

Can anyone give me details on using "bindkey" to map the arrow keys for history 
movement. I am running an HP735 HPUX 9.05.

Thanks
Tom Gower
compdsgn@postoffice.ptd.net