For more readability I would like to add spaces around the arguments in a service's check command. Running a nagios check outputs an error as it seems to want everything on one likeso:
One line check_command definition
However I would like to spcify the check command likeso:
separate lines check command
It’s not possible. Nagios parses configuration attributes by the logic “attribute value \n” so that’s how it has to look.
Other options include breaking it up into multiple check commands, thereby reducing the amount of macros. It’s hard to say since you don’t share the actual text.
On that note, do not share text in pictures. Ever. For any reason. Copy the text and format it as monospaced. If it contains sensitive information, redact it from the text, don’t draw on a picture. Sharing text as pictures is a great way to become very unpopular with colleagues, support personell, and anyone else you come in contact with who has to be able to access the actual text itself, or just want to be able to read it (they may use a screen reader).
In MATLAB, how do you tell where in the code a variable is getting output?
I have about 10K lines of MATLAB code with about 4 people working on it. Somewhere, someone has dumped a variable in a MATLAB script in the typical way:
foo
Unfortunately, I do not know what variable is getting output. And the output is cluttering out other more important outputs.
Any ideas?
p.s. Anyone ever try overwriting Standard.out? Since MATLAB and Java integration is so tight, would that work? A trick I've used in Java when faced with this problem is to replace Standard.out with my own version.
Ooh, I hate this too. I wish Matlab had a "dbstop if display" to stop on exactly this.
The mlint traversal from weiyin is a good idea. Mlint can't see dynamic code, though, such as arguments to eval() or string-valued figure handle callbacks. I've run in to output like this in callbacks like this, where update_table() returns something in some conditions.
uicontrol('Style','pushbutton', 'Callback','update_table')
You can "duck-punch" a method in to built-in types to give you a hook for dbstop. In a directory on your Matlab path, create a new directory named "#double", and make a #double/display.m file like this.
function display(varargin)
builtin('display', varargin{:});
Then you can do
dbstop in double/display at 2
and run your code. Now you'll be dropped in to the debugger whenever display is implicitly called by the omitted semicolon, including from dynamic code. Doing it for #double seems to cover char and cells as well. If it's a different type being displayed, you may have to experiment.
You could probably override the built-in disp() the same way. I think this would be analagous to a custom replacement for Java's System.out stream.
Needless to say, adding methods to built-in types is nonstandard, unsupported, very error-prone, and something to be very wary of outside a debugging session.
This is a typical pattern that mLint will help you find:
So, look on the right hand side of the editor for the orange lines. This will help you find not only this optimization, but many, many more. Notice also that your variable name is highlighted.
If you have a line such as:
foo = 2
and there is no ";" on the end, then the output will be dumped to the screen with the variable name appearing first:
foo =
2
In this case, you should search the file for the string "foo =" and find the line missing a ";".
If you are seeing output with no variable name appearing, then the output is probably being dumped to the screen using either the DISP or FPRINTF function. Searching the file for "disp" or "fprintf" should help you find where the data is being displayed.
If you are seeing output with the variable name "ans" appearing, this is a case when a computation is being done, not being put in a variable, and is missing a ';' at the end of the line, such as:
size(foo)
In general, this is a bad practice for displaying what's going on in the code, since (as you have found out) it can be hard to find where these have been placed in a large piece of code. In this case, the easiest way to find the offending line is to use MLINT, as other answers have suggested.
I like the idea of "dbstop if display", however this is not a dbstop option that i know of.
If all else fails, there is still hope. Mlint is a good idea, but if there are many thousands of lines and many functions, then you may never find the offender. Worse, if this code has been sloppily written, there will be zillions of mlint flags that appear. How will you narrow it down?
A solution is to display your way there. I would overload the display function. Only temporarily, but this will work. If the output is being dumped to the command line as
ans =
stuff
or as
foo =
stuff
Then it has been written out with display. If it is coming out as just
stuff
then disp is the culprit. Why does it matter? Overload the offender. Create a new directory in some directory that is on top of your MATLAB search path, called #double (assuming that the output is a double variable. If it is character, then you will need an #char directory.) Do NOT put the #double directory itself on the MATLAB search path, just put it in some directory that is on your path.
Inside this directory, put a new m-file called disp.m or display.m, depending upon your determination of what has done the command line output. The contents of the m-file will be a call to the function builtin, which will allow you to then call the builtin version of disp or display on the input.
Now, set a debugging point inside the new function. Every time output is generated to the screen, this function will be called. If there are multiple events, you may need to use the debugger to allow processing to proceed until the offender has been trapped. Eventually, this process will trap the offensive line. Remember, you are in the debugger! Use the debugger to determine which function called disp, and where. You can step out of disp or display, or just look at the contents of dbstack to see what has happened.
When all is done and the problem repaired, delete this extra directory, and the disp/display function you put in it.
You could run mlint as a function and interpret the results.
>> I = mlint('filename','-struct');
>> isErrorMessage = arrayfun(#(S)strcmp(S.message,...
'Terminate statement with semicolon to suppress output (in functions).'),I);
>>I(isErrorMessage ).line
This will only find missing semicolons in that single file. So this would have to be run on a list of files (functions) that are called from some main function.
If you wanted to find calls to disp() or fprintf() you would need to read in the text of the file and use regular expresions to find the calls.
Note: If you are using a script instead of a function you will need to change the above message to read: 'Terminate statement with semicolon to suppress output (in scripts).'
Andrew Janke's overloading is a very useful tip
the only other thing is instead of using dbstop I find the following works better, for the simple reason that putting a stop in display.m will cause execution to pause, every time display.m is called, even if nothing is written.
This way, the stop will only be triggered when display is called to write a non null string, and you won't have to step through a potentially very large number of useless display calls
function display(varargin)
builtin('display', varargin{:});
if isempty(varargin{1})==0
keyboard
end
A foolproof way of locating such things is to iteratively step through the code in the debugger observing the output. This would proceed as follows:
Add a break point at the first line of the highest level script/function which produces the undesired output. Run the function/script.
step over the lines (not stepping in) until you see the undesired output.
When you find the line/function which produces the output, either fix it, if it's in this file, or open the subfunction/script which is producing the output. Remove the break point from the higher level function, and put a break point in the first line of the lower-level function. Repeat from step 1 until the line producing the output is located.
Although a pain, you will find the line relatively quickly this way unless you have huge functions/scripts, which is bad practice anyway. If the scripts are like this you could use a sort of partitioning approach to locate the line in the function in a similar manner. This would involve putting a break point at the start, then one half way though and noting which half of the function produces the output, then halving again and so on until the line is located.
I had this problem with much smaller code and it's a bugger, so even though the OP found their solution, I'll post a small cheat I learned.
1) In the Matlab command prompt, turn on 'more'.
more on
2) Resize the prompt-y/terminal-y part of the window to a mere line of text in height.
3) Run the code. It will stop wherever it needed to print, as there isn't the space to print it ( more is blocking on a [space] or [down] press ).
4) Press [ctrl]-[C] to kill your program at the spot where it couldn't print.
5) Return your prompt-y area to normal size. Starting at the top of trace, click on the clickable bits in the red text. These are your potential culprits. (Of course, you may need to have pressed [down], etc, to pass parts where the code was actually intended to print things.)
You'll need to traverse all your m-files (probably using a recursive function, or unix('find -type f -iname *.m') ). Call mlint on each filename:
r = mlint(filename);
r will be a (possibly empty) structure with a message field. Look for the message that starts with "Terminate statement with semicolon to suppress output".
Every time when I finish running a matlab code collection on command line, when I exit matlab, the standard output just gets messed. I can still use the terminal window, but whatever I typed won't show up on the screen, leaving me either type with my eyes blind, or open up a new terminal and excessively cd to the old place.
This happens every single time when I use make to run a matlab collection, and since I'm working a lot on this, it turns out to be very annoying. Does anyone know what's the problem here and how should I fix it?
As was pointed out in the comments, the makescript is probably dumping "bad" characters to the terminal. You could prevent this (but possibly lose useful information) by redirecting the output - instead of sending it to the terminal window, you can send it to a file, or even /dev/null ("the great bit bucket in the sky").
The underlying problem, however, is that your makefile is even sending these characters to the terminal in the first place. I would recommend that you pipe the output to a file with something like make > myDump.txt, then examine the resulting file to see what is going on, and where in your makefile the problem is created. It is possible that you will still be getting some output when you do this - that's because by default > redirects stdout only, and not stderr - a second output stream used for error messages. You can redirect both to a file with make 2>&1 myDump.txt.
You have already seen the recommendation to use stty sane to restore the status of the terminal - I am repeating it here in case someone only looks at answers, and not at comments; but I don't take credit for it :-).
I wrote a small program to read input, and print the result, and loop. Like REPL.
And I want to get the input I have inputed before when I press the up key on the keyboard and edit this input, like what bash or zsh does. I have no idea about the implementation. I also searched the web but no result I want. Could someone point a way for me? Or give me some articles to read?
The point is: How to print an EDITABLE line on screen?
I have no personal experience with it, but it's my understanding that Term::ReadLine provides command editing functionality with history. It's even part of the perl distribution.
You just need to:
Store a history of user input, just like bash and zsh do;
Listen for ↑ key presses, just like bash and zsh do;
Display the last command when ↑ is pressed. Just like, you guessed it, bash and zsh.
This is what programming is all about: breaking down big problems we don't know how to solve into smaller problems that we do know how to solve, or can more-easily figure out how to solve. So if you don't know how to do any of the things I listed above, try writing some code, reading API documentation, looking for answers on Google/Stack Overflow, or – once again – breaking them down into sub-problems.
if your point is "print" maybe you need Term::Screen. example code here: code.
otherwise if your point is "history", man/perldoc Term::ReadLine.
By "cleaned" I mean formatting inputs such as "a1b2c3" into "A1B 2C3" or "5551234567" into "(555) 123-4567". I figure we have few options:
As the user is typing. For instance, when a user is typing a postal code, all letters are instantly capitalized, or after the user types 3 digits of a phone number, it puts brackets around them.
When the field loses focus.
Never. Formatting happens on the server-side only, just before it is inserted into the DB. The user never gets to see how it was formatted unless it is displayed on the site somewhere.
(3b) If there were form errors, or on the confirmation page. If there are form errors and the form needs to be re-displayed, the formatting on the valid inputs will appear, or if you have a confirmation page (are these inputs correct?) they will show there.
Never ever. Data should be dumped into the database as-is and only formatted in the template/view just before it is displayed back to the user.
What do you think? I think I like (2). Reminds me of how code-formatting works in Visual Studio (happens when you close a brace or type a semi-colon).
I like to either filter the field just after it loses focus (when it is critical that the field be formatted correctly before they move on to the next field - which is rarely), or I filter the field content as soon as the user hits the "SUBMIT" button (or whatever you want to call it) to send the data to the server.
This has a few advantages for me:
The user's input is not interrupted with annoying "auto-corrections" - being auto-corrected can sometimes feel like demonic possession if it is not done well.
The user really neither cares, nor needs to know that you do not want the (,), or -, in your phone number field... so take it out quietly for them. No notes, or instructions needed.
Also, I ALWAYS filter the field values anyway to protect against any kind of code-injection attacks (which are alarmingly easy to pull off if you know what you are doing). I have read about entire databases being compromised because the author did not remove potential SQL markup from submitted data.... it makes me shudder.
It also allows me to check for ALL input errors (if any), or non-filled-out required fields and report a single set of issues to the user at a single time... I have been to sites that give you so many messages while filling out a form it feels a bit like having a nagging relative over your shoulder.
I'd go with either (1) or (2), depending on the kind of input. (1) is probably most user-friendly if done right, but it will be more complex to implement neatly (e.g., what happens if I delete a digit from a hyphenated phone number - or a hyphen?). Go with (1) if you can afford it, otherwise (2).
I follow the same method I use for validation. Once on the client side, once on the server side. Whether it happens on loose focus or as they type it doesn't really matter.
As the user is typing. For instance, when a user is typing a postal code, all letters are instantly capitalized, or after the user types 3 digits of a phone number, it puts brackets around them.
This type of input is excellent for things such as entering serial codes or CD keys for software or games. I notice a lot of people get confused whether or not the code is case sensitive or if they should be inputting the dashes as well.
If you have an iPhone you'll notice when entering a phone number it is also auto formatted with brackets and spaces as you enter it. But this often turns out to be confusing as a partially typed number is not always 'grouped' correctly.
Answer: It all depends on context.