[Bash-completion-devel] Boletín Wayup - En Fal las Quemamos los Precios!!!

2009-03-18 Thread Dpto. Marketing






  
  

  


  
Si no 
puede visualizar correctamente este mensaje pulse aqui

  


___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel


Re: [Bash-completion-devel] wget completion

2009-03-18 Thread Freddy Vulto
 gibboris at gmail.com writes:
 Hello,
 I just tried a first attempt for the wget completion (see attachement).

Here're some thoughts.  See also proposed diff at the end.

The `=' in long options isn't mandatory for wget, so I personally
think you'd better leave them off as default suffix.  The `='-suffix
has also recently been removed from the `alias' completion as the
thought was to keep completion minimalistic.  Another problem with
appending `=' is that unless you specify `-o nospace', a superfluous
space is appended after the `='.  Problem with `-o nospace' is that
it's either set or unset for *all* wget completions:
complete-options cannot be modified from within a completion
(bash-4.0 contains a `compopt' builtin which supposedly makes this
possible).

Users may or may not use the `=' option assignment.  We can support
both users by splitting the current word on `=' at the beginning of
`_wget()'.  See diff.

But maybe you can omit completing long options and call `_longopt()'
for that?  (Perhaps we should drop '='-suffixing from _longopt() as
well because of the nospace problem?)  See diff.

The `I' sed-modifier is a GNU-extension to sed and therefore cannot
be used for the bash-completion package.

 - long option where a short option exists are not given in the
 completion of long options ([ [:blank:]]), why ?  Don't know
 myself, but I feel I should handle them separatly.

I'm not sure what's your intention but I found it annoying and
counter-intuitive as I tend to remember long options and I'm missing
options, e.g. --output-file...

 - any way to complete (or at least to give a clue about the value
 expected) for an option waiting for a numeric parameter ?

I don't know of any way to do this without violating the minalistic
approach...  So perhaps we shouldn't want this.

 - doubts about completion of main argument, ideas :
 f -- tp://
 h -- ttp
 http -- s:// | ://
 w | http://w; | https://w; -- www.
  
Seems useful to me.


Greetings,

Freddy Vulto
http://fvue.nl

---8-

--- wget.sh.orig2009-03-18 21:30:04.0 +0100
+++ wget.sh 2009-03-18 21:03:42.0 +0100
@@ -12,6 +12,12 @@
 cur=`_get_cword`
 prev=${COMP_WORDS[COMP_CWORD-1]}
 
+# If `cur' is long option containing `=', reassign prev and cur
+if [[ $cur == --*=* ]]; then
+   prev=${cur/=*}
+   cur=${cur/*=}
+fi
+
 case $prev in
--progress)
COMPREPLY=( $( compgen -W 'bar dot' -- $cur ) )
@@ -64,19 +70,10 @@
 
 case $cur in
--*)
-   #parametered ones first (only those defined above)
-   #then long non-parametered ones
-   COMPREPLY=( $( compgen -W --progress --bind-address 
--restrict-file-names
--prefer-family
---directory-prefix \
-   --load-cookies --save-cookies --post-file --certificate 
--ca-certificate
--private-key
---random-file \
-   --egd-file --secure-protocol --append-output --input-file \
-   --certificate-type --private-key-type --ca-directory 
--exclude-domains
--domains --follow-tags
---ignore-tags \
-   \
-   $(wget -h | sed -n 's/^[ [:blank:]]*\(--[a-z-]*\)[ 
[:blank:]].*$/\1/Ip')
-- $cur ) )
+   _longopt wget
return 0
;;
+
-*)
COMPREPLY=( $( compgen -W $(wget -h | sed -n 's/^[
[:blank:]]*\(-[a-z46]\).*$/\1/Ip') -- $cur ) )
return 0


___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel