* Permissions directories
@ 2000-06-22 1:04 Chmouel Boudjnah
2000-06-22 9:34 ` Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Chmouel Boudjnah @ 2000-06-22 1:04 UTC (permalink / raw)
To: zsh-workers
Hi,
Is there any reason why now the directories in $fpath need to be 755
and not 775 or 777 ?
I know i can use compinit -i but yeck i just want to know the reason.
--
MandrakeSoft Inc http://www.mandrakesoft.com
San-Francisco, CA USA --Chmouel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Permissions directories
2000-06-22 1:04 Permissions directories Chmouel Boudjnah
@ 2000-06-22 9:34 ` Bart Schaefer
0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2000-06-22 9:34 UTC (permalink / raw)
To: zsh-workers
On Jun 21, 6:04pm, Chmouel Boudjnah wrote:
} Subject: Permissions directories
}
} Is there any reason why now the directories in $fpath need to be 755
} and not 775 or 777 ?
Put the following in a file in your $fpath, using a name that starts with
an underscore:
--- 8< --- cut here --- 8< ---
#compdef -p *
_message -r Gotcha!
--- 8< --- cut here --- 8< ---
Do you really want just anyone to be able to drop files into directories
that compinit searches for completion definitions?
This is not so much a problem since compinit is also checking ownership
of the files in those directories. I think it's got the test wrong for
the .zwc files, though -- e.g. if the parent of a directory in $fpath
is writable, I believe under the current tests I could still create a
trojan .zwc file there that would be used in place of the directory of
the same basename.
While I'm on the subject, though, I've been finding a number of problems
with the new compinit. For one thing, the test
(( $+functions[$_i_name] + $_i_wfiles[(I)$_i_file] )) && continue
is a nice idea, but it doesn't work in practice -- the test can't be for
whether the *function* is already defined, it has to be a test for whether
it has already been defined *by compinit*. I don't want the test to fail
if *I've* already explicitly autoloaded a name, I only want it not to
parse the #compdef lines from files of the same name out of two different
directories. I think we need a local assoc or array for this, not the
$functions parameter.
The other problem is that when I answer "y" to the question "there are
insecure directories -- proceed?" I expected that to mean that it would
USE those directories, not ignore them. If it's going to skip those
directories anyway, why bother to ask the question? Giving me a choice
between no directories and half of them is no choice at all; it just
leaves me with a partly-working completion system, which is baffling.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Permissions directories
@ 2000-06-22 11:07 Sven Wischnowsky
2000-06-22 16:23 ` Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 2000-06-22 11:07 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> ...
>
> This is not so much a problem since compinit is also checking ownership
> of the files in those directories. I think it's got the test wrong for
> the .zwc files, though -- e.g. if the parent of a directory in $fpath
> is writable, I believe under the current tests I could still create a
> trojan .zwc file there that would be used in place of the directory of
> the same basename.
Digest files are not used automatically, they have to be named in
$fpath. The patch makes zwc be not excluded for testing purposes.
> While I'm on the subject, though, I've been finding a number of problems
> with the new compinit. For one thing, the test
>
> (( $+functions[$_i_name] + $_i_wfiles[(I)$_i_file] )) && continue
>
> is a nice idea, but it doesn't work in practice -- the test can't be for
> whether the *function* is already defined, it has to be a test for whether
> it has already been defined *by compinit*. I don't want the test to fail
> if *I've* already explicitly autoloaded a name, I only want it not to
> parse the #compdef lines from files of the same name out of two different
> directories. I think we need a local assoc or array for this, not the
> $functions parameter.
Right, the patch does that, too.
> The other problem is that when I answer "y" to the question "there are
> insecure directories -- proceed?" I expected that to mean that it would
> USE those directories, not ignore them. If it's going to skip those
> directories anyway, why bother to ask the question? Giving me a choice
> between no directories and half of them is no choice at all; it just
> leaves me with a partly-working completion system, which is baffling.
Oh. Right, too. Or should we give that as a choice at the prompt
(don't use/use/ignore)?
Bye
Sven
Index: Completion/Core/compinit
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/compinit,v
retrieving revision 1.5
diff -u -r1.5 compinit
--- Completion/Core/compinit 2000/06/20 07:15:39 1.5
+++ Completion/Core/compinit 2000/06/22 11:06:37
@@ -348,7 +348,7 @@
typeset _i_q
_i_wdirs=( ${^fpath}(Nf:g+w:,f:o+w:,^u0u${EUID}) )
- _i_wfiles=( ${^~fpath:/.}/^([^_]*|*~|*.zwc)(N^u0u${EUID}) )
+ _i_wfiles=( ${^~fpath:/.}/^([^_]*|*~)(N^u0u${EUID}) )
case "${#_i_wdirs}:${#_i_wfiles}" in
0:0) _i_q= ;;
@@ -358,16 +358,20 @@
esac
if [[ -n "$_i_q" ]]; then
- if [[ "$_i_fail" = ask ]] &&
- ! read -q "?There are insecure $_i_q, continue [yn]? "; then
- unfunction compinit compdef
- unset _comp_dumpfile _comp_secure compprefuncs comppostfuncs \
- _comps _patcomps _postpatcomps _compautos _lastcomp
-
- return 1
+ if [[ "$_i_fail" = ask ]]; then
+ if ! read -q "?There are insecure $_i_q, continue [yn]? "; then
+ unfunction compinit compdef
+ unset _comp_dumpfile _comp_secure compprefuncs comppostfuncs \
+ _comps _patcomps _postpatcomps _compautos _lastcomp
+
+ return 1
+ fi
+ _i_wfiles=()
+ _i_wdirs=()
+ else
+ (( $#_i_wfiles )) && _i_files=( "${(@)_i_files:#(${(j:|:)_i_wfiles})}" )
+ (( $#_i_wdirs )) && _i_files=( "${(@)_i_files:#(${(j:|:)_i_wdirs})/*}" )
fi
- (( $#_i_wfiles )) && _i_files=( "${(@)_i_files:#(${(j:|:)_i_wfiles})}" )
- (( $#_i_wdirs )) && _i_files=( "${(@)_i_files:#(${(j:|:)_i_wdirs})/*}" )
fi
_comp_secure=yes
fi
@@ -393,12 +397,15 @@
fi
fi
if [[ -z "$_i_done" ]]; then
+ typeset -A _i_test
+
for _i_dir in $fpath; do
[[ $_i_dir = . ]] && continue
(( $_i_wdirs[(I)$_i_dir] )) && continue
for _i_file in $_i_dir/^([^_]*|*~|*.zwc)(N); do
_i_name="${_i_file:t}"
- (( $+functions[$_i_name] + $_i_wfiles[(I)$_i_file] )) && continue
+ (( $+_i_test[$_i_name] + $_i_wfiles[(I)$_i_file] )) && continue
+ _i_test[$_i_name]=yes
read -rA _i_line < $_i_file
_i_tag=$_i_line[1]
shift _i_line
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Permissions directories
2000-06-22 11:07 Sven Wischnowsky
@ 2000-06-22 16:23 ` Bart Schaefer
0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2000-06-22 16:23 UTC (permalink / raw)
To: zsh-workers
On Jun 22, 1:07pm, Sven Wischnowsky wrote:
} Subject: Re: Permissions directories
}
} Bart Schaefer wrote:
}
} > I think it's got the test wrong for
} > the .zwc files, though -- e.g. if the parent of a directory in $fpath
} > is writable, I believe under the current tests I could still create a
} > trojan .zwc file there
}
} Digest files are not used automatically, they have to be named in
} $fpath.
Oh, so the documentation under "Autoloaded Functions" is wrong?
[...]
} Right, the patch does that, too.
[...]
} Oh. Right, too.
Thanks.
} Or should we give that as a choice at the prompt (don't use/use/ignore)?
It wouldn't hurt, but it's not as important. However, I think you have
the prompt wrong ... isn't the default answer usually the first one? You
have "... continue [yn]?" but if I just hit return that's taken as n, not
y, so it should be "... continue [ny]?". I was about to append a patch,
but then I became indecisive as to the default *should* be, particularly
if we allow three choices.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-06-22 16:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-22 1:04 Permissions directories Chmouel Boudjnah
2000-06-22 9:34 ` Bart Schaefer
2000-06-22 11:07 Sven Wischnowsky
2000-06-22 16:23 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).