setopt and alias questions

setopt and alias questions

[Sweth Chandramouli]

	two questions:
	
	1) is there some way to force setopt to list the status
of all options?  right now, it only lists the status of those that
have been changed from the shell defaults; if you don't remember the
defaults of all of the options, however, this can cause problems.
if this can't currently be done, can the feature be added?

	2) does zsh not support tracking or exporting of aliases?
	
	-- sweth.

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

Re: setopt and alias questions

[Bart Schaefer]

Please stop using <zsh-users@math.gatech.edu>.  The mailing list address is
now <zsh-users@sunsite.auc.dk>.  Forwarding through the old address won't
work forever.  Your Mail-Followup-To: header should be fixed, too.

On Feb 7,  7:37pm, Sweth Chandramouli wrote:
} Subject: setopt and alias questions
}
} 	1) is there some way to force setopt to list the status
} of all options?

Yes:  setopt kshoptionprint

However, this produces all sorts of lovely double-negatives like

noalwayslastprompt    off
noautolist            off
noautomenu            off
nolistambiguous       off
nolistbeep            off
nolisttypes           off

} right now, it only lists the status of those that
} have been changed from the shell defaults

Yes.  This was done so that the output of "setopt" with no args would not
change radically from 3.0.x to 3.1.x.  Of course, I then disagreed (and
still do) with the decision to turn so many options "on" by default.

} 	2) does zsh not support tracking or exporting of aliases?

Zsh does not export aliases.  I don't know what you mean by "tracking."

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

Re: setopt and alias questions

[Sweth Chandramouli]

On Sun, Feb 07, 1999 at 05:59:31PM -0800, Bart Schaefer wrote:
> Please stop using <zsh-users@math.gatech.edu>.  The mailing list address is
> now <zsh-users@sunsite.auc.dk>.  Forwarding through the old address won't
> work forever.  Your Mail-Followup-To: header should be fixed, too.
	oops.  i never noticed that i was using the old address.

> On Feb 7,  7:37pm, Sweth Chandramouli wrote:
> } 	1) is there some way to force setopt to list the status
> } of all options?
> 
> Yes:  setopt kshoptionprint
> 
> However, this produces all sorts of lovely double-negatives like
> 
> noalwayslastprompt    off
> noautolist            off
> noautomenu            off
> nolistambiguous       off
> nolistbeep            off
> nolisttypes           off
	
	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.  it probably needs a test at the beginning to see
what the current value of kshoptionprint is, but since i won't ever
be setting that option manually now that i have this function, i
didn't bother to put it in.

allopt () {
   builtin setopt kshoptionprint
   for OPT_PAIR in ${(f)$(builtin setopt)} ; do
      OPT_VALUE=$((${#${(M)OPT_PAIR% *}}%2))
      OPT_NAME=${OPT_PAIR% *}
      if [[ ${OPT_NAME#no} != ${OPT_NAME} ]] ; then
         OPT_VALUE=$(( (${OPT_VALUE}+1)%2 )) &&
            OPT_NAME=${OPT_NAME#no};
      fi;
      if [[ ${OPT_VALUE} = 1 ]] ; then
         OPT_VALUE='on'
      else OPT_VALUE='off'
      fi;
      echo ${(r:28:)OPT_NAME} ${OPT_VALUE}
   done
   builtin unsetopt kshoptionprint
}

> } 	2) does zsh not support tracking or exporting of aliases?
> 
> Zsh does not export aliases.  
	so aliases to be present in all interactive shells must be
defined in .zshrc?  aside from global aliases, is there any reason
to not put all of my aliases into equivalent functions?  (other than
memory use, of course.)

> I don't know what you mean by "tracking."
	ksh tracks aliases (it used to be an option to the alias command,
but now i believe it is mandatory) as a security/efficiency aid.  tracking
means that when an alias is first invoked, its definition is modified as
though all commands it calls were defined with their full paths.  this
speeds things up a little because all subsequent invocations of that
alias don't have to find the commands in PATH, and is a bit more secure
in that 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 ".".

	-- sweth.

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

Re: setopt and alias questions

[Bart Schaefer]

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.

It should be noted that this function only works properly in zsh 3.1.2
and later, because prior to that the first line of output from `setopt`
with kshoptionprint on, is "Current option settings".

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.

} it probably needs a test at the beginning to see
} what the current value of kshoptionprint is, but since i won't ever
} be setting that option manually now that i have this function, i
} didn't bother to put it in.

The canonical way to do this is

	setopt localoptions kshoptionprint

The "localoptions" causes the values of all options to revert when the
function returns to their state at the time the function was entered.

Of course, both localoptions and kshoptionprint will be mis-reported in
the resulting output, but that's no big deal.

} 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.  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.)

}       if [[ ${OPT_NAME#no} != ${OPT_NAME} ]] ; then
}          OPT_VALUE=$(( (${OPT_VALUE}+1)%2 )) &&
}             OPT_NAME=${OPT_NAME#no};
}       fi;

Using our "norcs" example, this changes OPT_VALUE from 1 to 0 by using
modulo arithmetic again, and changes OPT_NAME from norcs to rcs (still
plus all the trailing space).

If the option hadn't started with "no", nothing would have changed.

}       if [[ ${OPT_VALUE} = 1 ]] ; then
}          OPT_VALUE='on'
}       else OPT_VALUE='off'
}       fi;
}       echo ${(r:28:)OPT_NAME} ${OPT_VALUE}
}    done
}    builtin unsetopt kshoptionprint
} }

That part is pretty obvious.

So here's what I hope is a somewhat more readable version of the whole
function:

    allopt() {
	builtin setopt localoptions kshoptionprint
	local OPT_PAIR OPT_VALUE OPT_NAME
	for OPT_PAIR in "${(@f)$(builtin setopt)}"
	do
	    OPT_NAME=${OPT_PAIR%% *}
	    OPT_VALUE=${OPT_PAIR##* }
	    if [[ ${OPT_NAME#no} != $OPT_NAME ]]
	    then
		OPT_NAME=${OPT_NAME#no}
		[[ $OPT_VALUE == off ]] && OPT_VALUE=on || OPT_VALUE=off
	    fi
	    echo ${(r:21:)OPT_NAME} ${OPT_VALUE}
	done
    }

I chose (r:21:) because that's how wide the actual "setopt" output is.

} > Zsh does not export aliases.  
} 	so aliases to be present in all interactive shells must be
} defined in .zshrc?

Yes.

} 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.)

} > I don't know what you mean by "tracking."
} tracking means that when an alias is first invoked, its definition is
} modified as though all commands it calls were defined with their full
} paths.

Ah.  No, zsh definitely does not do this.

Zsh does modify function definitions the first time that they're loaded
to contain the expansions of any already-extant aliases, and then never
expands aliases when executing the function.  So once a function has
been loaded, you can change your aliases all you like without affecting
the function.  There's a lot about this in the FAQ.

} [...] 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.
"Tracking" of aliases for speed purposes wouldn't be of much use in zsh
unless the hashcmds option is off.

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.)

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

Re: setopt and alias questions

[Sweth Chandramouli]

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@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

Re: setopt and alias questions

[Bart Schaefer]

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.)

	ov=${(L)${${ov/on/OFF}/off/on}}

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

Re: setopt and alias questions

[Sweth Chandramouli]

On Mon, Feb 08, 1999 at 10:45:50AM -0800, Bart Schaefer wrote:
> } > } 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)
	i don't like error messages, however, so i use the loop to test
for the existance of autoloadable files before doing the actual autoload:

for DIRNAME in ${fpath} ; do
   if [[ -x ${DIRNAME}/*(.x:t) ]] ; then
      autoload ${DIRNAME}/*(.x:t)
   fi;
done;

> Can you figure out what this is doing?  
	what my modulo2 binary-value loop did much more painfully.

> (Not terribly obfuscated, I admit.)
> 
> 	ov=${(L)${${ov/on/OFF}/off/on}}
> 
> 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?
	:s, which makes me wonder why the ${param/pattern/replacement}
construct was added at all.

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

Re: setopt and alias questions

[Bart Schaefer]

On Feb 8,  2:15pm, Sweth Chandramouli wrote:
} Subject: Re: setopt and alias questions
}
} On Mon, Feb 08, 1999 at 10:45:50AM -0800, Bart Schaefer wrote:
} > 
} > 	autoload $^fpath/*(.:t)
} 	i don't like error messages, however, so i use the loop to test
} for the existance of autoloadable files before doing the actual autoload:
} 
} for DIRNAME in ${fpath} ; do
}    if [[ -x ${DIRNAME}/*(.x:t) ]] ; then
}       autoload ${DIRNAME}/*(.x:t)
}    fi;
} done;

That loop will never autoload anything -- unless there happens to be a
file in the current directory with the same name as one in ${DIRNAME}.
Do you see why?

Once that's fixed, the [[ -x ... ]] is completely redundant with *(.x) --
it always succeeds, unless *(.x) doesn't match any files.  (Is that the
error you're worried about?)

Finally, there's no requirement that files have the execute mode set in
order to be autoloadable, so using (x) may miss some.

} > What two characters, inserted twice, give the same effect in 3.0.5?
} 	:s, which makes me wonder why the ${param/pattern/replacement}
} construct was added at all.

The patterns in ${param/pattern/replacement} can contain glob characters
which are matched against the value of $param, but the "patterns" in
${param:s/pattern/replacement} are matched as literal strings without
globbing.  The older :s form is borrowed from csh, the newer form is
from (I think) bash.

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

Re: setopt and alias questions

[Sweth Chandramouli]

On Mon, Feb 08, 1999 at 11:44:03AM -0800, Bart Schaefer wrote:
> On Feb 8,  2:15pm, Sweth Chandramouli wrote:
> } Subject: Re: setopt and alias questions
> }
> } On Mon, Feb 08, 1999 at 10:45:50AM -0800, Bart Schaefer wrote:
> } > 
> } > 	autoload $^fpath/*(.:t)
> } 	i don't like error messages, however, so i use the loop to test
> } for the existance of autoloadable files before doing the actual autoload:
> } 
> } for DIRNAME in ${fpath} ; do
> }    if [[ -x ${DIRNAME}/*(.x:t) ]] ; then
> }       autoload ${DIRNAME}/*(.x:t)
> }    fi;
> } done;
> 
> That loop will never autoload anything -- unless there happens to be a
> file in the current directory with the same name as one in ${DIRNAME}.
> Do you see why?
	yes--because i need to start cut&pasting my functions rather
than typing them in.  that should be -n, not -x.

> Once that's fixed, the [[ -x ... ]] is completely redundant with *(.x) --
> it always succeeds, unless *(.x) doesn't match any files.  (Is that the
> error you're worried about?)
	that's the error--the glob complains if there are no functions to
autoload in fpath, and i find myself copying my .zshrc to enough new
machines where i haven't had a chance to set up any functions in .zfunc
and can't nfs-mount my "real" home directory that the error message can
get annoying.  with the -n, it just tests to see if there are, in fact,
any executable files in that directory; if not, it won't try to autoload
(and thus glob).

> Finally, there's no requirement that files have the execute mode set in
> order to be autoloadable, so using (x) may miss some.
	that's a requirement i picked up from someone on this list, or
maybe it was in the examples--it lets me "turn off" autoloading of individual
functions by removing their execute bit.  i have some functions that i don't
want to use anymore, for example, but which i want to keep around so i don't
have to reinvent the wheel if i later on want to create a similar function;
this lets me keep them all in one dir.

	-- sweth.

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

Re: setopt and alias questions

[Bart Schaefer]

On Feb 8,  2:59pm, Sweth Chandramouli wrote:
} Subject: Re: setopt and alias questions
}
} On Mon, Feb 08, 1999 at 11:44:03AM -0800, Bart Schaefer wrote:
} > On Feb 8,  2:15pm, Sweth Chandramouli wrote:
} > } 
} > } for DIRNAME in ${fpath} ; do
} > }    if [[ -x ${DIRNAME}/*(.x:t) ]] ; then
} > }       autoload ${DIRNAME}/*(.x:t)
} > }    fi;
} > } done;
} > 
} > That loop will never autoload anything -- unless there happens to be a
} > file in the current directory with the same name as one in ${DIRNAME}.
} > Do you see why?
} 	yes--because i need to start cut&pasting my functions rather
} than typing them in.  that should be -n, not -x.

That won't work either (and my remark about "unless there happens to be a
file in the current directory" is wrong as well).  Filename generation is
not applied to the strings inside the [[ ... ]].  Try running this:

	function fx() {
	    mkdir /tmp/x
	    echo "echo hello" > /tmp/x/x
	    chmod +x /tmp/x/x
	    echo /tmp/x/*(x)
	    [[ -n /tmp/x/*(x) ]] && echo Got nonzero string
	    [[ -f /tmp/x/*(x) ]] && echo Globbed a file
	    [[ -x /tmp/x/*(x) ]] && echo Globbed executable file
	    [[ -x /tmp/x/x ]] && echo Found executable file
	    rm -r /tmp/x
	    [[ -n /tmp/x/*(x) ]] && echo Still got nonzero string
	    [[ -x /tmp/x/x ]] || echo Found no executable file
	}

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

Re: setopt and alias questions

[Sweth Chandramouli]

On Mon, Feb 08, 1999 at 12:55:00PM -0800, Bart Schaefer wrote:
> On Feb 8,  2:59pm, Sweth Chandramouli wrote:
> } Subject: Re: setopt and alias questions
> }
> } On Mon, Feb 08, 1999 at 11:44:03AM -0800, Bart Schaefer wrote:
> } > On Feb 8,  2:15pm, Sweth Chandramouli wrote:
> } > } 
> } > } for DIRNAME in ${fpath} ; do
> } > }    if [[ -x ${DIRNAME}/*(.x:t) ]] ; then
> } > }       autoload ${DIRNAME}/*(.x:t)
> } > }    fi;
> } > } done;
> } > 
> } > That loop will never autoload anything -- unless there happens to be a
> } > file in the current directory with the same name as one in ${DIRNAME}.
> } > Do you see why?
> } 	yes--because i need to start cut&pasting my functions rather
> } than typing them in.  that should be -n, not -x.
> 
> That won't work either (and my remark about "unless there happens to be a
> file in the current directory" is wrong as well).  Filename generation is
> not applied to the strings inside the [[ ... ]].  

	are you sure about this?  the above (with -n instead of -x) works
fine for me--or at least, the filename generation part does.  what i hadn't
realized until now is that the error i was trying to catch, about there not
being any matches for that glob, was being generated by the shell instead
of the autoload command; any dirs in fpath that don't contain executable
files, then, would cause the shell to return the same error when attempting
the glob in the [[ ... ]], which defeats the purpose of the entire loop.
	(globbing in the test operator _definitely_ does work, however.)
	could a flag be added to the list of glob qualifiers that says "if no
matches are found, quietly return nothing but a non-zero exit status"?  i
think "q" (for "quiet") is still free.

	-- sweth.

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

Re: setopt and alias questions

[Bart Schaefer]

On Feb 12,  2:34pm, Sweth Chandramouli wrote:
> Subject: Re: setopt and alias questions
> On Mon, Feb 08, 1999 at 12:55:00PM -0800, Bart Schaefer wrote:
> > That won't work either (and my remark about "unless there happens to be a
> > file in the current directory" is wrong as well).  Filename generation is
> > not applied to the strings inside the [[ ... ]].  
> 
> 	are you sure about this?  the above (with -n instead of -x) works
> fine for me--or at least, the filename generation part does.

Did you try running the fx function?  Here it is again:

        function fx() {
            mkdir /tmp/x
            echo "echo hello" > /tmp/x/x
            chmod +x /tmp/x/x
            echo /tmp/x/*(x)
            [[ -n /tmp/x/*(x) ]] && echo Got nonzero string
            [[ -f /tmp/x/*(x) ]] && echo Globbed a file
            [[ -x /tmp/x/*(x) ]] && echo Globbed executable file
            [[ -x /tmp/x/x ]] && echo Found executable file
            rm -r /tmp/x
            [[ -n /tmp/x/*(x) ]] && echo Still got nonzero string
            [[ -x /tmp/x/x ]] || echo Found no executable file
        }

The output I get is:

  zagzig% fx
  /tmp/x/x
  Got nonzero string
  Found executable file
  Still got nonzero string
  Found no executable file

Note that "Globbed ..." was never output.  If I replace all the [[ ... ]]
with [ ... ] (single brackets), THEN I get

  zagzig% fx
  /tmp/x/x
  Got nonzero string
  Globbed a file
  Globbed executable file
  Found executable file
  zsh: no matches found: /tmp/x/*(x)

> 	could a flag be added to the list of glob qualifiers that says "if no
> matches are found, quietly return nothing but a non-zero exit status"?  i
> think "q" (for "quiet") is still free.

There already is such a flag; it's (N) for NULL_GLOB, which acts like:

  zagzig% setopt nullglob
  zagzig% fx
  /tmp/x/x
  Got nonzero string
  Globbed a file
  Globbed executable file
  Found executable file
  Still got nonzero string
  Found no executable file

(This again with [ ... ] but NOT with [[ ... ]].)

Re: setopt and alias questions

[Sweth Chandramouli]

	for those who are interested, here's the final version
of my allopt function, which now can take arguments at the
command line to use as patterns for selecting which options
to display, and which uses bart's much nicer way of swapping
the on/off settings (or at least, the pre-3.1.5-pws-5 version
of bart's way):

allopt () {
   listalloptions () {
      builtin setopt localoptions kshoptionprint
      for OPT_PAIR in "${(f)$(builtin setopt)}" ; do
         OPT_VALUE=${OPT_PAIR##* }
         OPT_NAME=${OPT_PAIR%% *}
         if [[ ${OPT_NAME#no} != ${OPT_NAME} ]] ; then
            OPT_VALUE=${(L)${${OPT_VALUE:s/on/OFF}:s/off/on}} &&
               OPT_NAME=${OPT_NAME#no};
         fi;
         echo ${(r:21:)OPT_NAME} ${OPT_VALUE}
      done
   };
   if [[ -n $@ ]] ; then
      listalloptions | egrep "${@:s/ /|/}"
   else listalloptions
   fi;
}

	and here's a quick completion hack, inside of an
anonymous code block so that localoptions will work:

{
   builtin setopt localoptions kshoptionprint
   optlist=("${${(f)$(builtin setopt)}%% *}")
   compctl -k optlist setopt allopt
}

	-- sweth.

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

Re: setopt and alias questions

[Bart Schaefer]

On Feb 8,  2:46pm, Sweth Chandramouli wrote:
} Subject: Re: setopt and alias questions
}
} 	for those who are interested, here's the final version

We have to stop meeting like this ...

}    if [[ -n $@ ]] ; then
}       listalloptions | egrep "${@:s/ /|/}"
}    else listalloptions
}    fi;

That doesn't work, does it?

    zsh% argv=(x y z)
    zsh% print -l "${@:s/ /|/}"
    x
    y
    z
    zsh% print -l "${(j:|:)@}"
    x|y|z
    zsh% print -l "${*:gs/ /|/}"
    x|y|z

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

Re: setopt and alias questions

[Phil Pennock]

Typing away merrily, Bart Schaefer produced the immortal words:
> }    if [[ -n $@ ]] ; then
> }       listalloptions | egrep "${@:s/ /|/}"
> }    else listalloptions
> }    fi;
> 
> That doesn't work, does it?
> 
>     zsh% argv=(x y z)
>     zsh% print -l "${@:s/ /|/}"
>     x
>     y
>     z
>     zsh% print -l "${(j:|:)@}"
>     x|y|z
>     zsh% print -l "${*:gs/ /|/}"
>     x|y|z

That last one is dependent upon the first character of $IFS being a
space and is perhaps, IMnsHO, not suited for use in a function?

Nice though.
-- 
--> Phil Pennock ; GAT d- s+:+ a23 C++(++++) UL++++/I+++/S+++/B++/H+$ P++@$
L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++
DI+ D+ G+ e+ h* r y?