Re: setopt and alias questions

[Sweth Chandramouli <sweth@xxxxxxxxxxxxxxxxxxxx>]

On Sun, Feb 07, 1999 at 11:33:43PM -0800, Bart Schaefer wrote:
> On Feb 7, 11:52pm, Sweth Chandramouli wrote:
> } Subject: Re: setopt and alias questions
> }
> } 	here's the workaround i just came up with; it depends on the
> } fact that the options that already start with "no" (e.g. notify) are,
> } by default, on.
> 
> Believe it or not, the C code for "setopt" depends on exactly the same
> fact.
	i was wondering if it did that, or if a list of options that began
with no was hard-coded in somewhere.

[snip]
> 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.
	as am i when i try it again this morning.  the only thing that i can
think of is that at some point, i was redefining setopt (hence the use of
builtin setopt, until i switched the name of the function), and maybe 
accidentally redefined setopt tot something that then worked with the
new version that i came up with.  if that were the case, though, it should
have broken when i added in the builtin precommand.
	i also remember that the output of whatever i was using in the for
loop last night only had one space between the option and its value, like:

noignoreeof on
nointeractive off

	when i use the for loop that i have now, however, all of the 
intermediate spaces are still there.  (note to self: no more playing with 
scripts late at night unless i promise to use some sort of revision control.)

	just as a side note, the @ flag isn't necessary, at least with my
environment; once the quotes are there, the f flag takes care of tokenizing
each line.


> } allopt () {
> }    builtin setopt kshoptionprint
> }    for OPT_PAIR in ${(f)$(builtin setopt)} ; do
> }       OPT_VALUE=$((${#${(M)OPT_PAIR% *}}%2))
> 
> Wow.  No offense, but if we ever decide to have an obfuscated zsh code
> contest, that's got to be a leading candidate.  
	there are a lot more that i'm far too ashamed of to share; rather
than simplify the actual usages, however, i've found myself just spending
forty lines of comments to explain what i was doing.  (most of my recent
questions have been a part of my effort to hyper-comment my init files
before teaching a little course on "fun with zsh" for a bunch of my coworkers
later this month.)

> For the confused, this
> gets the trailing " on" or " off" (note leading space!) from a string
> like "norcs                 on", gets its length (3 for on, 4 for off)
> and uses mod-2 arithmetic to turn that into 1 for on or 0 for off.
> 
> }       OPT_NAME=${OPT_PAIR% *}
> 
> This sets OPT_NAME to "norcs                " (note all the trailing
> spaces).  Better might be ${OPT_PAIR%% *} to trim the spaces; doubling
> the % makes it consume the longest match rather than the shortest.  (I
> say "might be" because this function doesn't actually care whether the
> spaces are there or not.)
	again, the way i remember the output of the for loop, there weren't
any extra trailing spaces to match.  i still have no idea what i was doing,
though.

[snip]
> } 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. 


[snip]
> } [...] it can be used, by aliasing commands like ls, to help prevent 
> } problems caused by insecure paths--once a command that has been "wrapped"
> } by its alias has been invoked, subsequent invocations will refer back
> } to that original command, as opposed to, say, an evil trojan in the current
> } directory that would otherwise have been run by a PATH containing ".".
> 
> 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,
however.

> "Tracking" of aliases for speed purposes wouldn't be of much use in zsh
> unless the hashcmds option is off.
	the speed gain in ksh is pretty minimal nowdays anyway--i think it
was much more of an issue when processor cycles were at a premium.

> Anyway, that sounds like a pretty insecure way to give the illusion of
> greater security.  You're protected only if the alias is first invoked in
> a "safe" location -- if the evil trojan is already present the first time
> you use the alias, you're still in trouble.  (Unless it doesn't really
> work exactly the way you described it.)
	no, it works that way, and isn't very secure.  but it's a little
bit extra, and every little bit extra helps.  if you defined in your .profile
(for ksh) `alias -t ls=ls', then the odds are very good that you would ls
in your home directory (or some other presumed-safe dir) before switching
to a less-secure dir in which a trojan had been placed, thus saving you from
your unsafe path.  and a lot of trojans delete themselves once they have 
succeeded; if someone managed to drop a trojan ls into your home directory,
then the second time that you tried to ls, it would fail (because the ls
to which it had been tracked had been deleted), thus alerting you to the
fact that something wasn't right.

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

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@xxxxxxx> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html";>*</a>