I have several question:
If there is an error which has to be displayed to the client - It is a good thing to use STDERR stream instead of STDOUT? Or is it a trivial issue?
I want to add color support to output messages of this utility. Do I have to use some environment-tolerant framework for that?(it can be 256 color mode and "pure" one). Or how to make it tolerant?
I'm afraid to add colors to the output because clients may redirect output to log file. Can it potentially "break" anything because of that?
Please help me to build this utility in UNIX-way(Do one thing and do it well).
STDERR is better than STDOUT for errors for a couple of reasons. Redirecting the output won't hide the errors from you. You can prevent warnings from mixing with the output which makes it easier to parse/process in some cases.
You may want to look into the curses library which should support the ANSI color sets.
Utilities like ls will detect if their output is being redirected and drop the color codes so that log files, etc. don't get horked up. You should do the same.
Use STDERR. As for the colors, your concern can be alleviated by checking if the output is a tty before printing colors to it. During initialization, have a check that enables or disables colors on the fly. It's also good practice to have a --color=[on|off|auto] flag that a user can pass to select one explicitly.
Related
Program that I write often crashes leaving terminal in a S-Lang library state (similar to ncurses). I would want to add a check into development's branch Makefile main all target for such an improper state and and an automatic invocation of reset command. How to approach this task?
reset does two things; you can write a shell script which detects one of them:
it resets the terminal I/O modes (which a shell script can inspect using stty)
it sends escape sequences to the terminal (which more often than not will alter things in the terminal for which there is no suitable query/report escape sequence).
For the latter, you would find it challenging to determine the currently selected character set, e.g., line-drawing. If the terminal's set to show line-drawing characters, that's the usual reason for someone wanting to run reset (e.g., cat'ing a binary file to the screen).
There happens to be a VT320 feature (DECCIR) which can provide this information (which xterm implements):
but with regard to other terminals, you're unlikely to find it implemented:
(iTerm2 doesn't do it)
(nor does VTE). You can read an extract from the VT510 manual describing the feature on vt100.net
In the Chrome DevTools console, I keep getting error messages from certain places that do not actually affect my application's performance. Is there a way to filter out errors from those sources? (e.g., a YouTube iframe with errors, certain Chrome Extensions, etc.)
Yes, you can. You are able to filter messages from any file source by right-clicking on the file's name and line (something like main.js:15) and selecting Hide messages from *filename*. This will block all messages coming from that file (as is probably self-explanatory given what the button says).
Warning: This will also block messages using console.log() that might harm your debugging process, as well as errors that might come up in the future and be important (which you will now not know about). Use with caution on your own files. It should be harmless with files that aren't yours (again, things like iframes and extensions).
You can reverse the block by going up to the Filter dialog box near the top of the console (to the right of the eye icon) and deleting it. (This will also delete all other filters, so you could just remove one if you needed.) You can also more specifically filter messages using Filter, but for the purposes of the question (blocking messages from a certain file), it does the job the fastest and the best.
For more information, see: https://developers.google.com/web/tools/chrome-devtools/console/reference#filter. This also includes information on the other ways to more specifically filter console messages.
At the top of your console is a filter box. Here you can do
plain text search
regular expression search such as /\d+\s\d+/
attribute, such as url:pagead
negate any of the above with prefix -.
combine (AND) any of the above with space
For example -url:pagead will filter out all messages that have pagead in the url. There are two other attributes context: and source:, but I don't know what they do.
For example, def anon will show only messages that contain both def and anon (not necessarily together).
I have not found any way to OR two expressions (UNION).
see documentation
Icinga2 by default sends some of it's internal performance metrics to graphite, but I can't see a way to send my own performance data, but not the internal, so I was wondering if there was a way to configure graphite's carbon-cache to simply ignore certain metrics?
I know I could possibly work around this by using carbon-relay selectively relay on a subset, but this feels a cludge
I am also aware that it would be better if icinga2 also didn't send things I don't care about, which I will continue to look into, but i can see other use cases where I might want to stop storing certain metrics sooner than I might be able to push a code update to stop an application sending them
If I've understood your problem correctly, I think what you're looking for here is the carbon-cache blacklist. You specify a regular expression to ignore particular patterns of metrics.
For example, I use:
^prod\.service\..+$
... to ignore anything starting with prod.service (unfortunately it can get messy with escaping periods!). The file can be made of any number of lines like that.
I'm a little new to Grunt and am using it in our automated build system (on Windows). When running Grunt manually in the console, the coloring is extremely helpful. However, when running it in an automated setup, it results in color information in the build log, like this:
[4mRunning "sass:all" (sass) task [24m
The extra characters decrease the readability of the build log and I'd like to get rid of them.
I'm aware of the grunt.log.uncolor method for individual strings, but I'm wondering if there's a way to configure Grunt to output all logs without color information or if there's an existing plugin to do this. If not, I'll likely write my own plugin.
I feel like this would be a common occurrence — using Grunt in an automated system where you'd want to read the build log as plain text — so maybe I'm just missing something.
Of course, I finally find the answer right after asking the question...
Use the simple command-line option --no-color.
I was scouring the API but somehow missed the "Using the CLI" section of the documentation.
I need to add couple of assertions on the screen.
Lets Say I am on Page 1. I need to verify that some xxx text is displayed or not and button is displayed or not and also need to verify that the label of the button.
Please Help me how to add assertion in the monkey runner script..
Thanks
AFAIK Monkeyrunner doesn't have its own assertion mechanisms that would suit your need.
You can take a snapshot of your device and use some external image processing mechanism to verify interesting parts - but I know that wouldn't be ideal for text comparison.
You can use Python Imaging Library http://www.pythonware.com/products/pil/
Take a look at http://developer.android.com/guide/developing/tools/MonkeyImage.html, if you already have a MonkeyImage object that looks correct you can use MonkeyImage.sameAs() to compare it to the current MonkeyImage.
http://docs.python.org/library/pickle.html might be helpful for saving MonkeyImage objects. (I'd like to stress the might though)
The next version of the SDK should have a method of loading MonkeyImage objects from image files so you can compare it with less work. See https://review.source.android.com//#change,21478 for more info about this change.