umount completion context and tags

umount completion context and tags

[Silas Silva]

Hi there!

I was trying to tweak umount completion by using the tag-order style.
AFAIK, umount completion.  According to "umount ^Xh", we have:

    tags in context :completion::complete:umount::
        argument-rest options  (_arguments _mount (eval))
    tags in context :completion::complete:umount:argument-rest:
        device-labels device-paths directories  (_alternative _mount (eval)) 
        device-paths                            (_canonical_paths _canonical_paths _alternative _mount (eval))

It means that we have at least three tags:

    device-labels
    device-paths
    directories

device-labels is useless for me, so I tried to exclude it:

    zstyle ':completion:*:mount:*' tag-order '!device-labels'

But, it simply doesn't work!  ^Xh still gives me all tags.  Taking a
glance at the _mount completion, it has tags above hardcoded, but I
didn't look further.

In reality, what I want is to avoid behaviour like (in Linux):

    mount /dev/sdb1 /mnt/usb0
    cd /mnt
    umount u<Tab>
    umount udev  (!!!)

Any help?

Thank you!

-- 
Silas Silva

Re: umount completion context and tags

[Mikael Magnusson]

On Sun, Dec 14, 2014 at 2:15 PM, Silas Silva <silasdb@gmail.com> wrote:
> Hi there!
>
> I was trying to tweak umount completion by using the tag-order style.
> AFAIK, umount completion.  According to "umount ^Xh", we have:
>
>     tags in context :completion::complete:umount::
>         argument-rest options  (_arguments _mount (eval))
>     tags in context :completion::complete:umount:argument-rest:
>         device-labels device-paths directories  (_alternative _mount (eval))
>         device-paths                            (_canonical_paths _canonical_paths _alternative _mount (eval))
>
> It means that we have at least three tags:
>
>     device-labels
>     device-paths
>     directories
>
> device-labels is useless for me, so I tried to exclude it:
>
>     zstyle ':completion:*:mount:*' tag-order '!device-labels'
>
> But, it simply doesn't work!  ^Xh still gives me all tags.  Taking a
> glance at the _mount completion, it has tags above hardcoded, but I
> didn't look further.
>
> In reality, what I want is to avoid behaviour like (in Linux):
>
>     mount /dev/sdb1 /mnt/usb0
>     cd /mnt
>     umount u<Tab>
>     umount udev  (!!!)
>
> Any help?
>
> Thank you!

That's weird in at least two ways. I get the style to work only if i
make it ":completion:*". Secondly, those are filesystem types, not
labels, and are only valid after -t afaik(?), and umount -t produces a
broken completion.

-- 
Mikael Magnusson

Re: umount completion context and tags

[Bart Schaefer]

On Dec 14, 11:15am, Silas Silva wrote:
}
} device-labels is useless for me, so I tried to exclude it:
} 
}     zstyle ':completion:*:mount:*' tag-order '!device-labels'
} 
} But, it simply doesn't work!  ^Xh still gives me all tags.

That's not what '!' does.  It doesn't remove the tags themselves from
the help output, it removes the *possible matches* for the tags when
performing an actual completion.  The tag name itself is still valid.

Also, are you completing after umount?  Because you used :mount: in
the zstyle name, so it's not going to apply to the umount command.

Like so (using "unsetopt alwayslastprompt" so that the listings aren't
overwritten each time I hit tab):

torch% umount 
/                         /dev/shm                  /sys                    
/boot                     /proc                     usbfs                   
/dev/hda1                 /proc/bus/usb             /var/lib/nfs/rpc_pipefs 
/dev/hda2                 /proc/sys/fs/binfmt_misc                          
/dev/pts                  sunrpc                                            
torch% zstyle ':completion:*:umount:*' tag-order '! device-labels'
torch% umount /

Now there are no labels, only paths, so there is a unique "/" prefix
and I have to hit tab a second time to get the list:

torch% umount /
/                         /dev/pts                  /proc/sys/fs/binfmt_misc
/boot                     /dev/shm                  /sys                    
/dev/hda1                 /proc                     /var/lib/nfs/rpc_pipefs 
/dev/hda2                 /proc/bus/usb                                     
torch% umount /

If you want the style for both mount and umount, you can use:

zstyle ':completion:*:(u|)mount:*' tag-order '! device-labels'

(Aside:  Interesting that the listing sort order ignores the slashes.  I
don't offhand know why that's the case.)

Re: umount completion context and tags

[Bart Schaefer]

[Sticking with zsh-users for now but this maybe should move to -workers]

On Dec 14,  4:15pm, Mikael Magnusson wrote:
} Subject: Re: umount completion context and tags
}
} >     umount u<Tab>
} >     umount udev  (!!!)
} 
} That's weird in at least two ways. I get the style to work only if i
} make it ":completion:*".

See previous message about :(u|)mount: ...?

} Secondly, those are filesystem types, not labels, and are only valid
} after -t afaik(?), and umount -t produces a broken completion.

Hmm.  On the latter point, "umount -t" works for me:

torch% umount -t 
adfs         eventpollfs  iso9660      qnx4         selinuxfs    usbdevfs
autofs       ext2         minix        ramfs        sockfs       usbfs
bdev         ext3         mqueue       reiserfs     swap         vboxsf
bfs          futexfs      nodev        relayfs      sysfs        vfat
binfmt_misc  hfs          ntfs         romfs        tmpfs        vxfs
cramfs       hpfs         pipefs       rootfs       udf          xfs
devpts       hugetlbfs    proc         rpc_pipefs   ufs          xiafs

(same zsh session as my previous reply, with the '! device-labels' in
the tag-order).

In what more specific way is it broken for you?  Which branch of the
'case "$OSTYPE"' is taken in _mount on your host?

On the former point, I get:

torch% umount u<TAB>
torch% umount usbfs 

Looking at _complete_debug output, usbfs is being completed as a device
label because there are no matches to "u" for either device-paths or
directories.  The tag-order '!' style only applies when the other tags
do have possible matches.

Now, as to WHY it's being completed as a label, it's because /etc/mtab
has the line

usbfs /proc/bus/usb usbfs rw 0 0

so _mount assigns

dev_tmp=( /dev/hda2 usbfs /dev/hda1 sunrpc )

which subsquently interprets everything that doesn't start with a slash
as a device label.

-- 
Barton E. Schaefer

Re: umount completion context and tags

[Mikael Magnusson]

On Sun, Dec 14, 2014 at 5:53 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> [Sticking with zsh-users for now but this maybe should move to -workers]
>
> On Dec 14,  4:15pm, Mikael Magnusson wrote:
> } Subject: Re: umount completion context and tags
> }
> } >     umount u<Tab>
> } >     umount udev  (!!!)
> }
> } That's weird in at least two ways. I get the style to work only if i
> } make it ":completion:*".
>
> See previous message about :(u|)mount: ...?

Yeah, I somehow missed this missing u. It works fine if I add it again.

> } Secondly, those are filesystem types, not labels, and are only valid
> } after -t afaik(?), and umount -t produces a broken completion.
>
> Hmm.  On the latter point, "umount -t" works for me:

Sorry, I should have been more specific than just saying it's broken.
It produces this output for me:

% umount -t
---- file system type
\#                 auto\'       following  mqueue    to
\#vfat             available    fuse       msdos     try
[...]

I see now that the gentoo /etc/filesystems has some lines in it with
comments, and the completer doesn't remove them. How about instead of
this,

fss+=( ${$(</etc/filesystems)#\*} )

we use this?

fss+=( ${${${(f)"$(</etc/filesystems)"}:#\#*}#\*} )

> On the former point, I get:
>
> torch% umount u<TAB>
> torch% umount usbfs
>
> Looking at _complete_debug output, usbfs is being completed as a device
> label because there are no matches to "u" for either device-paths or
> directories.  The tag-order '!' style only applies when the other tags
> do have possible matches.

Here, you can use - as the first element of tag-order as
zstyle ':completion:*:umount:*' tag-order - '! device-labels'
and device-labels will never be used, not even as a fallback.

> Now, as to WHY it's being completed as a label, it's because /etc/mtab
> has the line
>
> usbfs /proc/bus/usb usbfs rw 0 0
>
> so _mount assigns
>
> dev_tmp=( /dev/hda2 usbfs /dev/hda1 sunrpc )
>
> which subsquently interprets everything that doesn't start with a slash
> as a device label.

I'm not even sure here what a device label is meant to be. I don't
suppose it's something mounted by LABEL=foo? My mount manpage mentions
partition labels, filesystem labels (and I know these are only
readable by root), and also 'those that are labeled "nodev"' appears.

-- 
Mikael Magnusson

Re: umount completion context and tags

[Bart Schaefer]

On Dec 14,  6:13pm, Mikael Magnusson wrote:
}
} I see now that the gentoo /etc/filesystems has some lines in it with
} comments, and the completer doesn't remove them. How about instead of
} this,
} 
} fss+=( ${$(</etc/filesystems)#\*} )
} 
} we use this?
} 
} fss+=( ${${${(f)"$(</etc/filesystems)"}:#\#*}#\*} )

Seems reasonable to me.

} > usbfs /proc/bus/usb usbfs rw 0 0
} >
} > so _mount assigns
} >
} > dev_tmp=( /dev/hda2 usbfs /dev/hda1 sunrpc )
} >
} > which subsquently interprets everything that doesn't start with a slash
} > as a device label.
} 
} I'm not even sure here what a device label is meant to be. I don't
} suppose it's something mounted by LABEL=foo?

I don't really know either.  However, it's clear that in this case "usbfs"
and "sunrpc" are virtual devices (since they appear in the first column
of the mtab line) so perhaps "label" is just a misnomer?

Either that, or _mount needs to interpret mtab positionally rather than
by guessing that slashes are devices and everything else is a label.

The "none" device (or label, or whatever) is filtered out.

} My mount manpage mentions
} partition labels, filesystem labels (and I know these are only
} readable by root), and also 'those that are labeled "nodev"' appears.

The only use of "nodev" in _mount is in _arguments arguments.

Re: umount completion context and tags

[Mikael Magnusson]

On Sun, Dec 14, 2014 at 6:47 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Dec 14,  6:13pm, Mikael Magnusson wrote:
> }
> } I see now that the gentoo /etc/filesystems has some lines in it with
> } comments, and the completer doesn't remove them. How about instead of
> } this,
> }
> } fss+=( ${$(</etc/filesystems)#\*} )
> }
> } we use this?
> }
> } fss+=( ${${${(f)"$(</etc/filesystems)"}:#\#*}#\*} )
>
> Seems reasonable to me.

I've commited this, and I'll leave the rest to someone who knows more
about things, I think.

> } > usbfs /proc/bus/usb usbfs rw 0 0
> } >
> } > so _mount assigns
> } >
> } > dev_tmp=( /dev/hda2 usbfs /dev/hda1 sunrpc )
> } >
> } > which subsquently interprets everything that doesn't start with a slash
> } > as a device label.
> }
> } I'm not even sure here what a device label is meant to be. I don't
> } suppose it's something mounted by LABEL=foo?
>
> I don't really know either.  However, it's clear that in this case "usbfs"
> and "sunrpc" are virtual devices (since they appear in the first column
> of the mtab line) so perhaps "label" is just a misnomer?
>
> Either that, or _mount needs to interpret mtab positionally rather than
> by guessing that slashes are devices and everything else is a label.
>
> The "none" device (or label, or whatever) is filtered out.
>
> } My mount manpage mentions
> } partition labels, filesystem labels (and I know these are only
> } readable by root), and also 'those that are labeled "nodev"' appears.
>
> The only use of "nodev" in _mount is in _arguments arguments.

-- 
Mikael Magnusson