| 1 |
On Fri, 11 Jan 2013 13:36:13 -0800 |
| 2 |
walt <w41ter@×××××.com> wrote: |
| 3 |
|
| 4 |
> On 01/11/2013 12:18 PM, Alan McKinnon wrote: |
| 5 |
> > On Fri, 11 Jan 2013 11:52:14 -0800 |
| 6 |
> > walt <w41ter@×××××.com> wrote: |
| 7 |
> > |
| 8 |
> >> On 01/11/2013 07:14 AM, Nikos Chantziaras wrote: |
| 9 |
> >>> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort |
| 10 |
> >>> -u); do echo "=$p"; done) |
| 11 |
> >> |
| 12 |
> >> qfile stopped working for me many weeks ago and I wish I could get |
| 13 |
> >> it working again. All the other portage utils work normally, |
| 14 |
> >> though. Any idea how to fix it? |
| 15 |
> >> |
| 16 |
> >> |
| 17 |
> > |
| 18 |
> > Error messages please |
| 19 |
> |
| 20 |
> #qfile bash |
| 21 |
> #echo $? |
| 22 |
> 1 |
| 23 |
> #qfile /bin/bash |
| 24 |
> app-shells/bash (/bin/bash) |
| 25 |
> #echo $? |
| 26 |
> 0 |
| 27 |
> |
| 28 |
> That's not the behavior I saw a few months back. Do you see |
| 29 |
> something different? |
| 30 |
> |
| 31 |
|
| 32 |
alanm@khamul ~ $ qfile bash |
| 33 |
alanm@khamul ~ $ echo $? |
| 34 |
1 |
| 35 |
alanm@khamul ~ $ qfile /bin/bash |
| 36 |
app-shells/bash (/bin/bash) |
| 37 |
alanm@khamul ~ $ echo $? |
| 38 |
0 |
| 39 |
alanm@khamul ~ $ |
| 40 |
|
| 41 |
I get the same as you, and Nikos' one-liner works as intended for me. |
| 42 |
|
| 43 |
I don't use qfile much so I can't honestly say if it changed recently, |
| 44 |
but it's behaviour is odd to say the least: |
| 45 |
|
| 46 |
alanm@khamul ~ $ pwd |
| 47 |
/home/alanm |
| 48 |
alanm@khamul ~ $ qfile media |
| 49 |
sys-fs/udisks (/media) |
| 50 |
alanm@khamul ~ $ |
| 51 |
alanm@khamul ~ $ |
| 52 |
alanm@khamul ~ $ qfile bash |
| 53 |
alanm@khamul ~ $ cd /bin/ |
| 54 |
alanm@khamul /bin $ qfile bash |
| 55 |
app-shells/bash (/bin/bash) |
| 56 |
alanm@khamul /bin $ |
| 57 |
|
| 58 |
This is the documented behaviour, explained by the "ROOT VARIABLE" |
| 59 |
section in the man page, but it just feels weird. The purpose of qfile |
| 60 |
is to tell you what installed a file system object (the argument to the |
| 61 |
command). The argument looks exactly like a path/filename and a |
| 62 |
reasonable man would treat it as such, but the command is |
| 63 |
prepending a hidden[1] string of ROOT VARIABLE when it doesn't get a |
| 64 |
hit on the first try. |
| 65 |
|
| 66 |
This might make sense to the dev, but it's |
| 67 |
certain to confuse everyone else. I would say that's not a bug, but |
| 68 |
it's an odd feature that probably needs to be thought through some more. |
| 69 |
|
| 70 |
|
| 71 |
|
| 72 |
[1] It's not really hidden as such. But it does do something very |
| 73 |
unexpected by default, and you have to read the man page first to |
| 74 |
find it. Feels to me like it violates the Law of Unexpected Behaviour |
| 75 |
|
| 76 |
|
| 77 |
-- |
| 78 |
Alan McKinnon |
| 79 |
alan.mckinnon@×××××.com |
Archives