Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: setopt and alias questions

On Feb 8, 10:30am, Sweth Chandramouli wrote:
} Subject: Re: setopt and alias questions
} > I'm also having some other problems with it.  I had to change the "for"
} > loop expression to:
} > 
} > 	for OPT_PAIR in "${(@f)$(builtin setopt)}"; do
} > 
} > in order to get the proper split-by-lines behavior.  I'm at a loss what
} > would let it work for you without the quotes and the @ flag.
} 	just as a side note, the @ flag isn't necessary

You're right.  I'm always throwing that in there needlessly; dunno why I
have it stuck in my head that any array expansion in " " needs it.

} > } aside from global aliases, is there any reason
} > } to not put all of my aliases into equivalent functions?
} > 
} > Probably not.  (Functions aren't exported either, though.)
} 	no, but they can be dropped in a .zfunc folder, so that
} only an autoload loop needs to be put in .zshrc for all shells to
} have access to them. 

You don't even need a loop.

	autoload $^fpath/*(.:t)

} > Hrm.  Zsh actually goes out of its way to make "." in $PATH work even if
} > the command has previously been hashed to somewhere (later) in the path.
} 	does it do this for all tokens in $path, or just "."?  the former
} makes sense; i don't think i would be very comfortable with the latter

It only does it for ".".  The way it works is that the command hash table
actually contains a pointer into the $path array.  When you execute "ls"
(for example), zsh fetches its hash entry (creating it if it doesn't find
it), finds in the hash entry a pointer to the string "/bin" within $path,
and then searches for that pointer in the array.  For each path element
that does not match the pointer, it checks if that element is ".".  If it
encounters "." before it finds itself back at the pointer to "/bin", it
executes ./ls, otherwise it executes /bin/ls.

(Now that I think about it, I'm surprised that it doesn't do this same
test for ".." or in fact for any path element beginning with "./" or
"../".  Not that I can think of any reason why somebody would put ".."
in their path.  Anyway ...)

Any time you change $PATH or $path, zsh throws out the command hash
table and (incrementally) rebuilds it, so the pointers into the array
are valid for purposes of this search.  And none of this happens for
commands that already have a full path.

} 	-- sweth, who secretly kind of likes the idea of an
} obfuscated zsh contest.

Can you figure out what this is doing?  (Not terribly obfuscated, I admit.)


BTW, that works only in 3.1.5-pws-something.  Exercise for the reader:
What two characters, inserted twice, give the same effect in 3.0.5?

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

Messages sorted by: Reverse Date, Date, Thread, Author