Nagios - adding spaces/tabs/newline Between arguments of Service Check Command - service

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).

Related

ISPF edit macro, how to prevent "Browse substituted" from occurring..?

Steve Ives provided ALLMEM code to run an edit macro against all members of a PDS, see here: How can I run ISPF Edit Macros in Batch
Some members in my PDS are too large (by default) for edit/view and suffer "Browse substituted" on the line:
Address 'ISPEXEC' 'EDIT DATAID('data1')',
'MEMBER('member1') MACRO('workmac')'
Since browse cannot run edit-macros the MACRO('workmac') bit does not come into play, there is no END command issued to return execution to the loop in ALLMEM, and the overall batch execution stops until I manually hit my PF3.
Is there any way I can force TSO to keep in EDIT mode for these large members?
Is there any way I can force TSO to keep in EDIT mode for these large
members?
Maybe.
ISPF Edit has an LRECL limit. If your members that are too large exceed this there isn't anything much you can do about that. If you want to engage in radical notions like splitting each record in two so they are editable, editing them, then reassembling each record pair back into a single record, that's a separate issue.
But maybe the problem isn't your LRECL, but the number of records. You might be able to do something about that.
You could try increasing the REGION parameter for your batch job in which you are running your ISPF Edit macro. I don't know if your personal ISPF settings matter in an ISPF batch job, but you could type EDITSET in an ISPF Edit session and ensure that the value for "Maximum initial storage allowed for Edit and View" is 0, just in case it matters.
Be advised that this may fix your problem, but it's possible your members are simply too big for ISPF Edit. In that case, you must find an alternate mechanism. Since you already have an edit macro, perhaps you could alter it, substituting your own code for ISPF Edit services, and run that code against your data. Perhaps this is an opportunity to learn the marvelous features of your SORT utility. Or awk. Lots of options.
If it is only certain members then it is not an LRECL issue, but strictly size. As cschneid mentioned you can try and maximize the storage available to Edit. However, if the member is really large then you wold eventually hit a storage limit. Currently Edit or View will switch to Browse in that case. If you are running Batch then this presents a problem as you describe. There is nothing that will keep it in Edit. RC=4 is already a documented return code for Browse being substituted, but if you are in batch then you probably end up in a display loop. One possible solution would be to have your own copy of ISRBROBA in ISPPLIB and have it set .RESP = END in the )INIT or )PROC section so as to force an END if BROWSE gets used. Since it is a batch job it is unlikely you would need the normal version of ISRBROBA. You would just make sure that your PANEL library is concatenated first.

Clear part of an IPython cell's output

Before I get reamed for this, I know there are some posts detailing how to clear ALL the output from a cell, but I'm interested in only clearing part of it.
Let me provide some background. I am creating a word-guessing game like LINGO where the user is prompted to guess a five-letter word, then using CSS to provide some visual feedback as to which letters are in the correct position, and which letters are in the word but in the wrong position. The way my program is structured, it displays the feedback after each guess and then prompts the user again and displays the guess. So something like this:
Guess a word: word
FEEDBACK
guess again: word
FEEDBACK
...
You get the picture. My goal is to come as close to duplicating LINGO as possible, which would mean removing the user input from the screen after it has been submitted and having it show a sequence of feedback. This to me means one of three things:
1) Find a way to clear part of the output
2) Find a way to prompt the user for text input without displaying it on the screen
3) Cache the user input, delete the all the output after each iteration, and display the cached guesses.
I've researched 1 and 2 and haven't been able to find anything. 3 would be a PITA so before I went to the trouble I thought I would ask.
1 think is either not possible or very difficult - it's hard in regular python, never mind Jupyter. In regular python, you'd probably use something like curses but I tried it in Jupyter and it affects the console Jupyter is running from - not the stdout in the notebook.
If you really wanted 2, you could probably write your own version of input that uses carriage return \r after stripping the trailing newline via writing a function that loops listening for keystrokes and submitting once a newline is pressed. The carriage return should mean that the next line overwrites the previous line.
3 Caching the input shouldn't be too difficult though I presume? Just store them in an array or something then you can display them back to the user after using IPython.display.clear_output.

CLUTO doc2mat specified stop word list not working

I am trying to convert my documents into vector-space format using doc2mat
On the website, it says I can use my specified text file where words are white-space separated or on multiple lines. So, I use some code similar to this one:
./doc2mat -mystoplist=stopword.txt -skipnumeric mydocuments.txt myvectorspace.txt
However, when I check the output .clabel file, it still has stop words that's in stopword.txt.
I really do not know how to do this. Someone help me out please? Thank you!
There's one important thing I should remember: I should include ALL the unwanted words in my stop list. This is somewhat difficult since there's always some variations available...
For example, if I want to exclude method I add it to my list. However, the resulting vocabulary may also contain method since there are words like methodist, methods, etc. Then doc2mat by default stems these words and I will still get method in the output.
Another thing is to make sure that "-nostop" option must be provided for user-specified stop list.

When should forms be cleaned?

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.

How can I control an interactive Unix application programmatically through Perl?

I have inherited a 20-year-old interactive command-line unix application that is no longer supported by its vendor. We need to automate some tasks in this application.
The most troublesome of these is creating thousands of new records with slightly different parameters (e.g. different identifiers, different names). The records have to be created in sequence, one at a time, which would take many months (and therefore dollars) to do manually. In most cases, creating a record has a very predictable pattern of keying in commands, reading responses, keying in further commands, etc. However, some record creation operations will result in error conditions ('record with this identifier already exists') that require a different set of commands to be exit gracefully.
I can see a few different ways to do this:
Named pipes. Write a Perl script that runs the target application with STDIN and STDOUT set to named pipes then sends the target application the sequence of commands to create a record with the required parameters, and then instructs the target application to exit and shut down. We then run the script as many times as required with different parameters.
Application. Find another Unix tool that can be used to script interactive programs. The only ones I have been able to find though are expect, but this does not seem top be maintained; and chat, which I recall from ages ago, and which seems to do more-or-less what I want, but appears to be only for controlling modems.
One more potential complication: I think the target application was written for a VT100 terminal and it uses some sort of escape sequences to do things like provide highlighting.
My question is what approach should I take? One of these, or something completely different? I quite like the idea of using named pipes and then having a Perl script that opens the FIFOs and reads and writes as required, as it provides a lot of flexibility, but from what I have read it seems like there's a lot of potential problems if I go down this path.
Thanks in advance.
I'd definitely stick to Perl for the extra flexibility, as chaos suggested. Are you aware of the Expect perl module? It's a lot nicer than the named pipe approach.
Note also with named pipes, you can't force the output coming back from your legacy application to be unbuffered, which could be annoying. I think Expect.pm uses pseudo-ttys to get around this problem, but I'm not sure. See the discussion in perlipc in the section "Bidirectional Communication with Another Process" for more details.
expect is a lot more solid than you're probably giving it credit for, but if I were you I'd still go with the Perl option, wanting to have a full and familiar programming language for managing the process and having confidence that whatever weird issues arise, there will be ways of addressing them.
Expect, either with the Tcl or Perl implementations, would be my first attempt. If you are seeing odd sequences in the output because it's doing odd terminal things, just filter those from the output before you do your matching.
With named pipes, you're going to end up reinventing Expect anyway.