Combining the GNU super-powers of tail and grep

(or: “Musings on the single-minded, relentless pursuit of perfection”…)

Saving this thought to possibly build upon  for later, adapted from something I just posted to Facebook:

I finally found a question on Stack Exchange that is right square in my wheelhouse, and was able to contribute an answer with which I am completely satisfied, because  I feel it is both better and more thoroughly considered and researched than the existing answers (because it is something I use almost every day, literally; so it is refined over years of usage)! It might seem silly — even useless — to an impartial observer, but I feel like this moment justifies my endless pursuit of perfection, never being satisfied with “good enough” and always chipping away at minor annoyances, trying to improve upon the status quo.

TL;DR: Oh frabjous day; this makes my borogoves all mimsy!
For the record, because one never knows how long a given site will last or when the current content may vanish; here is the content of my SE answer:

I see all these people saying to use `tail -f`, but I do not like the limitations of that! My favorite method of searching a file while also watching for new lines (e.g., I commonly work with log files to which are appended the redirected output of processes executed periodically via cron jobs) is:

`tail -Fn+0 /path/to/file|grep searchterm`

This assumes GNU tail and grep.
Supporting details from the tail manpage (GNU coreutils, mine is v8.22) [] :

> -F same as –follow=name –retry
> -n, –lines=K
> output the last K lines, instead of the last 10; or use -n +K to output starting with the Kth
> If the first character of K (the number of bytes or lines) is a >’+’, print beginning with the Kth item from the start of each file
>,otherwise, print the last K items in the file. K may have a multiplier
> suffix: b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024,
> GB 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y.
> With –follow (-f), tail defaults to following the file descriptor, >which means that even if a tail’ed file is renamed, tail will continue to >track its end. This default behavior is not desirable
> when you really want to track the actual name of the file, not >the file descriptor (e.g., log rotation). Use –follow=name in that case. >That causes tail to track the named file in a way that
> accommodates renaming, removal and creation.
So, the tail portion of my command equates to `tail –follow –retry –lines=+0`, where the final argument directs it to start at the beginning, skipping zero lines.


Key & Peele’s bittersweet final “Obama+Luther” sketch

Last nighOn last night’s episode of  “The Daily Show”, Keegan-Michael Key was Trevor’s guest, and he shared with the public his and Jordan Peele’s final “President Obama and his anger translator Luther” sketch. It was a beautiful, bittersweet thing.

Wireless (Bluetooth) Audio

intend to order the PowerBeats[This content started out life as  a normal post on my Facebook timeline, and when I showed Terra how long it was, she exclaimed “you should have put it on your blog!” So I have relocated  it here, to this vast, nearly-forgotten wasteland, so that we can laugh about it years from now, if is even still around then…

[Brace yourselves for a long, rambling post; sometimes one simply feels like writing and opining, you know?]
Following months of delays and [moderate] disappointment over what may have been Apple’s rockiest product rollout in recent history [though by no means a Samsung-level disaster], last night I read David Pogue‘s glowing review, with moderately informative [albeit obviously unscripted and without intentional direction] accompanying video [which seems to have originated directly from a Facebook Live broadcast/chat], and that, along with this similarly-effusive ZDNet article, I looked into Apple’s return/refund policy and after learning that ordering them would be as risk-free as it is reasonable to expect [fourteen days, full refund, no questions asked], I decided to pull the trigger and pre-order a set of Apple Airpods to try out as soon as they are [finally] released (now slated for mid-February). My favorite quotes from each of those sources:
Pogue@Yahoo: “These earbuds sound great. Easily as good as the wired EarPods, maybe better. Easily as good as Bluetooth earbuds costing $200 or $250 from other companies—so no, $160 really isn’t a gouging price.” :O
ZDNet: “after using Apple’s AirPods for over a week, it’s clear Apple still has it.”,
followed by: “Apple has once again set the bar for its competitors, and after using the likes of Samsung’s Gear IconX, it’s clear no one can even come close right now.” :O :O
I am looking forward to the final availability of these gadgets. We plan to do a full “ears-on” comparison of the Airpods versus other Bluetooth headphones intended for serious listening (tentatively, “BÖHM B66 Wireless” [manufacturer page][Amazon Listing](because I already had a pair of those on the way (for her; in fact, those were just delivered while I was working on this post) and Apple’s own over-ear-style “Powerbeats3 Wireless Earphones“[in the “Flash Blue” colorway, because we both feel like the “Shock Yellow” and “Siren Red” colors are nauseating, “gag me with a spoon”-level blech!] My intent st this time is to order said PowerBeats just days before the Airpods are set to arrive, so we have all three  sets of wireless headphones in hand at the same time for review/comparison and contrast purposes, but still within the safety of the two-week return windows of the various Apple items. While I do not currently plan to write up the comparison results for public consumption, that may change if enough folks express interest (or I feel enough like doing it) to make it worth the effort.
I must say, I am rather looking forward to finally catching up to the modern world of wireless-audio world, after several wireless (voice-intended) headsets over the years, plus one recent failed experiment with a set of Bluetooth 4.earbuds I picked up super-cheap from TNW’s “stocking stuffer” selection, and while those did in fact provide decent soun, aswell as functioning  rather well/intuitively, but were a total abject failure in wearability and one-handed-friendliness; I could not even get them around my head without the tips pulling out of one or both ears). I am also really looking forward to trying out (and learning) new things in the new year!Plus I have other big plans for the Winter Break (mandatory vacation week from work)
What is the worst that could happen? We love at least one of the options and decide to keep them, while returning the others? 😛
[//unsolicited blather complete–– for now… 😉 ]

Damn chef-server

Fun trying to install Chef server on OEL5 (RHEL5-based):

$ sudo cat /opt/chef-server/embedded/cookbooks/cache/chef-stacktrace.out
2013-05-08 14:47:07 (1368049627)
Generated at 2013-05-08 14:46:49 -0700
Mixlib::ShellOut::ShellCommandFailed: execute[boostrap-chef-server] (chef-server::bootstrap line 27) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '127'
---- Begin output of bin/bootstrap-chef-server ----
STDOUT: =ERROR REPORT==== 8-May-2013::14:46:49 ===
Failed to create cookie file '/home/bjackson/.erlang.cookie': eaccesescript: exception error: no function clause matching
---- End output of bin/bootstrap-chef-server ----
Ran bin/bootstrap-chef-server returned 127
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.1.0/lib/mixlib/shellout.rb:248:in `invalid!'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.1.0/lib/mixlib/shellout.rb:234:in `error!'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/mixin/shell_out.rb:36:in `shell_out!'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/provider/execute.rb:62:in `block in action_run'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/mixin/why_run.rb:52:in `call'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/mixin/why_run.rb:52:in `add_action'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/provider.rb:151:in `converge_by'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/provider/execute.rb:61:in `action_run'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/provider.rb:114:in `run_action'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource.rb:603:in `run_action'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/runner.rb:50:in `run_action'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/runner.rb:82:in `block (2 levels) in converge'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/runner.rb:82:in `each'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/runner.rb:82:in `block in converge'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection.rb:94:in `block in execute_each_resource'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/resource_collection.rb:92:in `execute_each_resource'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/runner.rb:81:in `converge'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/client.rb:404:in `converge'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/client.rb:469:in `do_run'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/client.rb:200:in `run'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/application.rb:190:in `run_chef_client'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/application/solo.rb:239:in `block in run_application'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/application/solo.rb:231:in `loop'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/application/solo.rb:231:in `run_application'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/lib/chef/application.rb:73:in `run'
/opt/chef-server/embedded/lib/ruby/gems/1.9.1/gems/chef-11.4.0/bin/chef-solo:25:in `<top (required)>'
/opt/chef-server/embedded/bin/chef-solo:23:in `load'
/opt/chef-server/embedded/bin/chef-solo:23:in `<main>'2013-05-08 14:47:10 (1368049630)

So I poked around looking for a plausible explanation of this, and found something related, though not precisely the same error, on SO:

Aha!  So it’s not supposed to be creating that cookie file in my home directory!  Thought that was odd… so obviously it’s using ~ or $HOME incorrectly at some point — or something is happening to make those not work as expected.

How about we ensure sudo isn’t preserving the environment?

$ sudo -i chef-server-ctl reconfigure

[... wait a bit ...]

chef-server Reconfigured!


The ORBlogs Test Site Fix

Recording for posterity:  the ORBlogs test site, running on Tomcat 6.0.18, was throwing this exception on the home page:

org.apache.jasper.JasperException: /WEB-INF/jsp/home.jsp(45,0) Unknown attribute type (java.util.List<net.bigbark.item.Item>) for attribute items.

The thing that was driving me crazy about this was that it ran just fine in a local Jetty container (started with “mvn jetty:run“).   The problem was this line in src/main/webapp/WEB-INF/tags/ui/article-list.tag:

<%@ attribute name="items" required="true" type="java.util.List<net.bigbark.item.Item>" %>

Apparently Jetty’s JSP implementation (which IIRC comes from Glassfish) allows one to use generic types, while the one in Tomcat (Jasper) does not.  Between the J2EE 1.4 tutorial documentation [1][2], the JSP 2.0 syntax reference [3], and the JSR-241 (JSP 2.1) final release specification [4], the only restriction I saw on the type attribute is that it must not reference a primitive type.  Does this mean that Jasper’s inability to handle a parameterized type reference is a bug?  It would appear that some Glassfish developer(s) allowed for this usage, which makes me wonder whether the corresponding Jasper developer(s) intentionally left out such support or simply never considered the possibility.

I changed the type attribute’s value to “java.util.List” (removed the generic type parameter), and the exception disappeared. C’est la vie!

P.S. Here is the full stack trace; maybe the search engines will pick up on it and it will help someone else in the future — but probably not. 🙂

Jan 27, 2009 2:23:22 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet default threw exception
org.apache.jasper.JasperException: /WEB-INF/jsp/home.jsp(43,8) Unknown attribute type (java.util.List<net.bigbark.item.Item>) for attribute items.
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(
at org.apache.jasper.compiler.ErrorDispatcher.jspError(
at org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(
at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(
at org.apache.jasper.compiler.Node$CustomTag.accept(
at org.apache.jasper.compiler.Node$Nodes.visit(
at org.apache.jasper.compiler.Node$Visitor.visitBody(
at org.apache.jasper.compiler.Node$Visitor.visit(
at org.apache.jasper.compiler.Node$Root.accept(
at org.apache.jasper.compiler.Node$Nodes.visit(
at org.apache.jasper.compiler.Validator.validate(
at org.apache.jasper.compiler.Compiler.generateJava(
at org.apache.jasper.compiler.Compiler.compile(
at org.apache.jasper.compiler.Compiler.compile(
at org.apache.jasper.compiler.Compiler.compile(
at org.apache.jasper.JspCompilationContext.compile(
at org.apache.jasper.servlet.JspServletWrapper.service(
at org.apache.jasper.servlet.JspServlet.serviceJspFile(
at org.apache.jasper.servlet.JspServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.ApplicationDispatcher.invoke(
at org.apache.catalina.core.ApplicationDispatcher.processRequest(
at org.apache.catalina.core.ApplicationDispatcher.doForward(
at org.apache.catalina.core.ApplicationDispatcher.forward(
at net.sourceforge.stripes.action.ForwardResolution.execute(
at net.sourceforge.stripes.controller.DispatcherHelper$7.intercept(
at net.sourceforge.stripes.controller.ExecutionContext.proceed(
at net.bigbark.stripes.util.ResourceBundleInterceptor.intercept(
at net.sourceforge.stripes.controller.ExecutionContext.proceed(
at net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept(
at net.sourceforge.stripes.controller.ExecutionContext.proceed(
at net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(
at net.sourceforge.stripes.controller.ExecutionContext.proceed(
at net.sourceforge.stripes.controller.ExecutionContext.wrap(
at net.sourceforge.stripes.controller.DispatcherHelper.executeResolution(
at net.sourceforge.stripes.controller.DispatcherServlet.executeResolution(
at net.sourceforge.stripes.controller.DispatcherServlet.doPost(
at net.sourceforge.stripes.controller.DispatcherServlet.doGet(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at net.sourceforge.stripes.controller.DynamicMappingFilter$2.doFilter(
at net.sourceforge.stripes.controller.StripesFilter.doFilter(
at net.sourceforge.stripes.controller.DynamicMappingFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at com.wideplay.warp.hibernate.SessionPerRequestFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.valves.AccessLogValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.jk.server.JkCoyoteHandler.invoke(
at org.apache.jk.common.HandlerRequest.invoke(
at org.apache.jk.common.ChannelSocket.invoke(
at org.apache.jk.common.ChannelSocket.processConnection(
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
at org.apache.tomcat.util.threads.ThreadPool$