On 10/23/2012 11:04 AM, Todd Fischer wrote:
> I use a tool, finds, I got from someone about 15 years ago. It simply
> does a recursive look for a string in all files of interest in a
> directory tree. When I get a big tarball of code that I don't intend to
> build, but want to grab some logic, I use finds. I have created a
> variety of variations of finds (which I usually later throw away) as my
> search needs change. Essentially finds is
>
> find . -exec fgrep -H "$1" {} \;
>
> but with lots and lots of other qualifiers. You can see a usable
> version at
>
> https://www.ridgerun.com/developer/wiki/index.php/Tip_of_the_day#finds_-_find_a_string_in_common_text_files
This looks useful.
I do something similar with the kernel. I have
a small one-line wrapper called armcgrep, which greps only the files in
the arch/arm section of the kernel source tree, and only those
with filenames matching the pattern "*.[chS]". Once things
are in the page cache, it works pretty fast.
'finds' looks similar, but it also omits some areas, and includes
things like Kconfig and others. I need to mentally digest all
the 'find' magic in it...
Thanks. Great tip!
> A recurring problem I had was finding the right /dev/ttyUSB? device. I
> have a nice USB to 4 serial port adaptor in a metal box I have screwed
> to my bench. I also use several USB serial dongles. For reasons I
> don't understand, they change association (at least under Ubuntu). I
> created two scripts lsuart and uart. The output of lsuart gives me
> information about the serial ports, like
>
> Available USB UARTs
> -------------------
> a:/dev/ttyUSB0 FTDI USB Serial Device 0000:00:04.1-4.1 (4 port jack A)
> b:/dev/ttyUSB1 FTDI USB Serial Device 0000:00:04.1-4.2 (4 port jack B)
> c:/dev/ttyUSB2 FTDI USB Serial Device 0000:00:04.1-4.3 (4 port jack C)
> :/dev/ttyUSB3 pl2303 0000:00:02.1-4.2 ()
> d:/dev/ttyUSB4 FTDI USB Serial Device 0000:00:04.1-4.4 (4 port jack D)
>
> In use
> ------
> /dev/ttyUSB4: 9705: picocom -b 115200 -r -l /dev/ttyUSB4
>
> I gave names (a, b, c, d) to the 4 fixed uarts. Now I look at which
> port my serial cable is plugged into - say the 3rd one, which I call c,
> and I can fire up picocom with the standard setting using
>
> uart c
>
> Sometimes I can't find a terminal session (too many windows open), so I
> use the PID from the In use section of the lsuart output to kill it.
>
> If others have the "where is my USB serial port" problem, I can love up
> my shell script (lsuart is a symbolic link to uart), which is around 200
> lines of ugly sysfs parsing.
Wow. I have this exact problem on one of our lab hosts, which has
about 10 boards attached. We don't power cycle it very often,
but when we do it sometimes messes up the USB settings, and we have
to go manually experiment to figure out which boards are attached
to which ttyUSB's again. It's a royal pain.
I'd be interested in seeing your shell script, ugly sysfs parsing and all.
Just out of curiosity - why picocom?
I've never heard of it. Is it just tradition or do you have a reason
to use it over minicom?
Thanks!
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
_______________________________________________
Celinux-dev mailing list
Celinux-dev@lists.celinuxforum.org
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
