adding tree option

[johnfreed]

Hi, you can ignore the first two items, as I included a lot of changes and then reverted them and split it into two pieces. The first piece, modularizing, adds a couple of more data points (like the Speed) and sets up a "parse" routine that returns either 0 (matched a line of output) or 1 (failed). This replaced the "continue" function in the original. Also some other changes as noted.

The second piece adds the -t (tree) option.

[jlhonora]

Hi John, excellent work! Sorry it took this long to answer.

Before merging I'd like to discuss a couple of things:

1. I'll do some formatting on the comments and the function spacing, I hope you don't mind.
2. I think it's misleading to show lsusb (usbutils) 007 as the output of lsusb -V. By seeing that our version conforms with the one in Linux someone could assume that the output is similar, which is not (specially with -v). Maybe we could set it to lsusb for Mac OS X, what do you think?
3. Why do you prefer the /bin/sh shebang? I've always heard that /usr/bin/env bash was more portable.

Thanks again for your work, after working this out I'll do a 1.0 release and point the Homebrew tap to it.

[johnfreed]

I'd like to do a little cleanup too. Just wanted to show it to you to see if you're OK with it in general. Suggestion: I will add you as a collaborator, we do the work together on the fork, then when you are happy with it you merge it.

Regarding #2 that is totally fine. Same with the Man page.

1. Well that is an interesting question I had not pondered before. Since we are not looking at portability (this is mac-only), I suppose it ultimately does not matter. I did a little thinking on the general topic and here is what I came up with. I see, for instance, #!/usr/bin/env python fairly often. That makes sense, because you might not know where python is (/usr/local/bin? /usr/bin?) and if you guess wrong the user is out of luck.

That's not the case with /bin/sh -- I think every *x system has it there. And that makes it per se "portable" in the sense that if you use sh syntax you win.

But every script must make SOME assumption about the system. There is always (it seems) a /usr/bin/env -- so that is useful. You could do "#!/usr/bin/env sh" (I suppose) which would say "use the first "sh" you find in the path" and similarly "#!/usr/bin/env bash" would use the first "bash" it finds. For portability purposes, however, I think "bash" is not on every system while "sh" is. (Sometimes if only as a symlink to bash.) So long as the script works, I am agnostic on this point.

The reason I stumbled on your project is because I have done a Macport of HPLIP (which allows my scanner to work on a Mac.) One of their diagnostics uses the lsusb program -- which was not ported to Mac! And voila. I got a kick out of developing the -t option and I saw your IOKit stub, which led me to take a look at the source for lsusb. It's not written using usblib, so I'm looking at doing a full rewrite of it. (After which, I hope, it will be portable to Mac and other systems -- thus eliminating the need for THIS port!) And my tree-building exercise should help. So thanks.

And thanks for the fast reply! It was about a year before I got a reply from the Macports folks, and my port still hasn't been accepted. :)

[johnfreed]

One other thought -- I reworked a bit (the -p option for instance) so as to make the output as close as possible to the Linux version, just in case somebody was parsing the output. I agree that doing so with -V goes too far! :)

[johnfreed]

I tested it with bash -- as I suspected there might have been a problem with some of that weird Bourne syntax, and there was. I'll use sed instead (which is more portable anyway).

[jlhonora]

OK with everything. I'll upload my changes to your repo and I'll also add you as a colab on this one so that you can move around freely :)

I didn't get what you mean with the -p option? Also, for your last comment, did you mean "I'll use sh instead"?

As for the IOKit branch that was my first project using IOKit, so please excuse any bad practice or errors. You'll be doing a rewrite of HPLIP or of the IOKit branch? I don't really have enough time to dig into darwin and IOKit (at least not as much as I would like), but if you want to take the lead I'd be glad to help. I think the only way of making a true alternative for lsusb is making use of the IOKit APIs.

[johnfreed]

ok i see you did your cleanup and now i've pretty much followed that (i think). please check. I had to make some changes to make it work under both bash and sh. I kept the "007" in the -V output to hint (I hope) that it is in sync with version 007 of the Linux lsusb

[jlhonora]

Thanks again for your excellent work! I released a 1.0 version that is already available through Homebrew.

Needless to say, you're invited to collaborate whenever you want to.

[johnfreed]

thanks :)

I did not look at your IOKit version, I meant doing a rewrite of lsusb using USBLIB in C. But it looks like a major can of worms because of limitations of the usblib port, which I'm looking at now.

On Mon, Feb 24, 2014 at 2:58 PM, Jose Luis Honorato < notifications@github.com> wrote:

Thanks again for your excellent work! I released a 1.0 version that is already available through Homebrew.

Needless to say, you're invited to collaborate whenever you want to.

— Reply to this email directly or view it on GitHubhttps://github.com/jlhonora/lsusb/pull/3#issuecomment-35888123 .