From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26808 invoked from network); 8 Feb 1999 15:33:58 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Feb 1999 15:33:58 -0000 Received: (qmail 3539 invoked by alias); 8 Feb 1999 15:32:49 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2117 Received: (qmail 3531 invoked from network); 8 Feb 1999 15:32:47 -0000 Date: Mon, 8 Feb 1999 10:30:38 -0500 From: Sweth Chandramouli To: zsh-users@sunsite.auc.dk Subject: Re: setopt and alias questions Message-ID: <19990208103038.A3447@astaroth.nit.gwu.edu> Mail-Followup-To: zsh-users@sunsite.auc.dk References: <19990207193735.A2060@astaroth.nit.gwu.edu> <990207175931.ZM8940@candle.brasslantern.com> <19990207235214.A2653@astaroth.nit.gwu.edu> <990207233343.ZM10079@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <990207233343.ZM10079@candle.brasslantern.com> 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 / (202) 994 - 8521 (V) / (202) 994 - 0458 (F) *