| 1 |
On Tuesday 23 December 2008 03:11:00 James wrote: |
| 2 |
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes: |
| 3 |
> > In cases where a quick command to display something doesn't exist, it's |
| 4 |
> > usually because it never occurred to the developer that there could be |
| 5 |
> > another way I find in my own experience that I usually know what driver |
| 6 |
> > is being used - I set the machines up after all - and if I do need to |
| 7 |
> > verify the driver, I also want the error messages related to it. Which |
| 8 |
> > are sitting in the log file |
| 9 |
> |
| 10 |
> If we followed that logic, why would we have things like |
| 11 |
> 'lspci'....? After all, we could go grepping (egrep fgrep etc) |
| 12 |
> who needs lspci anyway, certainly not an experienced admin.... |
| 13 |
> |
| 14 |
> |
| 15 |
> I get it. parse the file. No big deal, just surprised me. |
| 16 |
|
| 17 |
lspci lists hardware found on the PCI bus. It is far and away the best tool |
| 18 |
for finding out exactly what PCI hardware you have. Same for various other |
| 19 |
ls* tools for other buses. |
| 20 |
|
| 21 |
But like I said in the other mail, what is your point exactly? I'm sure a |
| 22 |
gnome-style app exists that interrogates HAL to find all this stuff out, I |
| 23 |
just don't know of one and would seldom use it. KDE also has some such thing, |
| 24 |
IIRC you get to it via Control Centre. |
| 25 |
|
| 26 |
I have my preferred method, it might not be a decent solution for you though. |
| 27 |
|
| 28 |
-- |
| 29 |
alan dot mckinnon at gmail dot com |
Archives