I send a SNMPv3 Trap and separate its fields using | and ; but these characters are also appearing in my trap, which confuses my parser at trap receiving end. I also tried most of the characters e.g. :,".><!##$%^&*()
but all these single line character appear in the trap. I also tried special symbols like €,¾,½ but Linux is not accepting these characters.
I need a single character separator.
Could you suggest any Key that can be entered from from Keyboard and works in Linux?
Assignment Operator Worked =, Since it is nearly impossible of assignment operator occurring in trap content.
Related
SETUP: Expect/Tcl Script in Linux
USE CASE:
Using expect to wait for the report of some status to be used in a $user_command.
expect -re "notify (.+)\n"
set status $expect_out(1,string)
send [string map [list SESSION "$status"] "$user_command"]
So when the application sends "notify running", then status is set to running.
For that a keyword STATUS in $user_command needs to be replaced with $status, such that, for example
"log STATUS to file"
becomes
"log running to file"
To see what is happing, I wrote
expect_tty -re "(.+)\n"
set status $expect_out(1,string)
send_user [string map [list SESSION "$status"] "$user_command"]
which works fine when running isolatedly. The output is
log someUserInput to file
when typing someUserInput to responde to expect_tty. However, as part of a larger script, the string map command it removes anything before the string replacement, so that the output becomes
" to file"
(without a newline) I checked for the uniqueness of variables in the script, so that this is not an issue.
QUESTION:
What is going on here? How can I make the script robust?
The string map command is exactly deterministic. At each character of its input string, in order, it considers whether any of the from strings in the mapping list match, in order, and if so it performs the replacement (with the paired to string) and goes on to consider the character immediately after the replaced substring. (The empty string is a special case: it's never matched.) The code to implement it is really quite stupid, but happens to be very cache friendly on modern computers so it's still very fast; more sophisticated and supposedly “faster” implementations have been tried, but found to be slower in practice with the kinds of maps usually encountered in the wild.
If the replacement is failing to apply, it's usually because the input string is not quite what you expect. In most programs this is rare, but it's more common with expect programs because the output of the terminal emulation engine inside them can include metacharacters for things like moving the cursor around and changing the color. (Often the easiest fix for that is to tell the spawned program that its terminal type is one that doesn't support such complex features, perhaps by setting the TERM environment variable to dumb.)
Thanks to #glennjackman:
The problem is due to applications reporting newline as \r\n, so that (.*)\n in
expect_tty -re "(.+)\n"
matches in expression 1 (the thing inside the brackets) something that includes \r at the end. With \r removing anything before it, string map seems to cut anything before the replaced string. The solution is to expect something that excludes \r, i.e.
expect -re ``(\[^\r\n\]+)``
which collects anything until end of line, whatsoever the format may be.
I am working on a ncursesw app that uses function keys.
Unfortunately it seems that there are some terminal emulators (notablly putty) that claim to be of terminal type "xterm" but send different escape sequences for the f1 to f4 keys from what a modern xterm sends (from some googling it seems that very old versions of xterm did the same).
ncursesw on my system just passes these escape sequences through to the app without interpreting them.
I would like to make my program accept these additional escape sequences for function keys. Is there a way to programatically add escape sequences to ncurses or will I need to write my own escape sequence interpreter?
Yes it is possible, using the call "define_key" ( http://invisible-island.net/ncurses/man/define_key.3x.html )
The documentation is not clear on whether it allows more than one escape sequence for a given "key" or not. My testing shows that it does allow it. So one can simply define the additional sequences.
define_key("\e[11~",KEY_F1);
define_key("\e[12~",KEY_F2);
define_key("\e[13~",KEY_F3);
define_key("\e[14~",KEY_F4);
You may want to surround this with a termname check so it only applies when the claimed terminal type is xterm (I did in my actual program but my actual program was written in pascal).
I have been reading The Unix Programming Environment & performing the included exercises. I understand that this work is somewhat dated, but I have found it to be an excellent resource.
In the first chapter, there are a few exercises in which the reader is presented with an interaction with the terminal & is asked to explain the interaction. Here is an example:
Exercise 1-1. Explain what happens with
$ date\#
In the text, it is explained that an # is to be interpreted as the line kill character. The equivalent on my system is ^u, but I can emulate the terminal in the book with stty kill #.
Based on the reading & my intuition, I would expect the invocation of date\# to return something to the effect of:
date#: command not found
The text supports this reasoning:
If you precede either # or # by a backslash \, it loses its special meaning. So to enter a # or #, type \# or \#.
My problem is that I cannot even type the example into my terminal. As soon as I type #, the line is erased. The backslash does not appear to escape the line kill character.
Assuming I am correct about how the escape character should interact with terminal control characters, how can I set up my system (Ubuntu GNU/Linux) to emulate the behavior from the text?
Here is another similar exercise:
Exercise 1-2. Most shells (though not the 7th edition shell) interpret # as introducing a comment, and ignore all text from the # to the end of the line. Given this, explain the following transcript, assuming your erase character is also #:
$ date
Mon Sep 26 12:39:56 EDT 1983
$ #date
Mon Sep 26 12:40:21 EDT 1983
$ \#date
$ \\#date
#date: not found
$
With my erase character set to #, it is impossible to replicate this transcript. The backslash does not appear to escape the erase character.
The Terminal gets and responds to your keystrokes before the Shell does. So the shell has no chance to escape the # since the terminal deletes the whole line first.
When you typed
stty kill #
you told the shell to tell the terminal to kill the line every time you press #
Type
stty kill ^u
and your shell will start to behave the way you expect and ^u will kill lines for you.
^v is the escape char for the terminal
\ is the escape char for the shell.
This is an antique question, about an even more antique book, but I'd like to set the record straight here because the currently accepted answer did not answer your question.
Believe it or not, when I learned UNIX from this book in 1985 (!), this part of the book was already antiquated, and the stuff about "#", "#" and "\" already did not work, and I remember being puzzled exactly like you on why it doesn't work, and whether I was doing something wrong. But it wasn't wrong per se - just out of date. Let me explain how in a previous era (perhaps a decade before the book was published?) this stuff was correct:
Before the advent of CRT terminals, there were "teletype" terminals - basically typewriters which print the characters you type (and the remote responses) on paper. On such teletypes, there was no "backspace". You couldn't erase something already typed. So the convention was that you typed a "#", and it erased, logically, the previous character. You'd still see both of them on the paper, but had to imagine both were deleted from the computer's input. So if you see on paper
helk#lo world
The computer actually received "hello world", with the "#" deleting the "k" behind it.
UNIX also allowed you to type one character, "#", to delete the entire line you just typed, if you made a lot of mistakes. So
oops I wrote a lot of crap I need to erase#hello world
Was again interpreted as just "hello world".
Finally, since sometimes you wanted to type an actual "#" or "#" characters and have them be taken literally, not as character-erase or line-erase commands, you also had an "escape character", which in very early days was "\". Note that this escape character was interpreted not by the shell, but rather by the Unix kernel's terminal driver, which communicated with the teletype.
When new CRT terminals appeared, these conventions were quickly phased out and became the ones we know today: The default erase character was no longer "#" but rather the backspace or delete key, and it really erases the character on the screen. The line-erase (somewhat confusingly known as "kill") became control-X or control-U. The escape character became control-V. You can also change these characters with the "stty" command, setting the "erase", "kill", or "lnext" attributes, but people rarely do. "stty -a" shows you all the current settings of these special characters (and many more).
Some programming languages e.g. Pascal and Java have a keyword or standard library function e.g. print to output a value, and a separate name println to output with a newline, but this has the disadvantage of giving the shorter/more obvious name to the behavior you don't usually want.
Other languages e.g. Basic and Python use print for the behavior you do usually want and have a special syntax such as a trailing ; or , to suppress the newline when required. This works, but one could argue that it would be more elegant/transparent to have different names for the two behaviors.
Are there - or have there ever been - any languages where output of a value with newline is spelled print, and there is a separate name for output without newline?
Tcl's puts prints the given string and the trailing newline by default, unless it's passed the -nonewline command-line option.
Had some spam issues on my server and, after finding out and removing some Perl and PHP scripts I'm down to checking what they really do, although I'm a senior PHP programmer I have little experience with Perl, can anyone give me a hand with the script here:
http://pastebin.com/MKiN8ifp
(It was one long line of code, script was called list.pl)
The start of the script is:
$??s:;s:s;;$?::s;(.*); ]="&\%[=.*.,-))'-,-#-*.).<.'.+-<-~-#,~-.-,.+,~-{-,.<'`.{'`'<-<--):)++,+#,-.{).+,,~+{+,,<)..})<.{.)-,.+.,.)-#):)++,+#,-.{).+,,~+{+,,<)..})<*{.}'`'<-<--):)++,+#,-.{).+:,+,+,',~+*+~+~+{+<+,)..})<'`'<.{'`'<'<-}.<)'+'.:*}.*.'-|-<.+):)~*{)~)|)++,+#,-.{).+:,+,+,',~+*+~+~+{+<+,)..})
It continues with precious few non-punctuation characters until the very end:
0-9\;\\_rs}&a-h;;s;(.*);$_;see;
Replace the s;(.*);$_;see; with print to get this. Replace s;(.*);$_;see; again with print in the first half of the payload to get this, which is the decryption code. The second half of the payload is the code to decrypt, but I can't go any further with it, because as you see, the decryption code is looking for a key in an envvar or a cookie (so that only the script's creator can control it or decode it, presumably), and I don't have that key. This is actually reasonably cleverly done.
For those interested in the nitty gritty... The first part, when de-tangled looks like this:
$? ? s/;s/s;;$?/ :
s/(.*)/...lots of punctuation.../;
The $? at the beginning of the line is the pre-defined variable containing the child error, which no doubt serves only as obfuscation. It will be undefined, as there can be no child error at this point.
The questionmark following it is the start of a ternary operator
CONDITION ? IF_TRUE : IF_FALSE
Which is also added simply to obfuscate. The expression returned for true is a substitution regex, where the / slash delimiter has been replaced with colon s:pattern:replacement:. Above, I have put back slashes. The other expression, which is the one that will be executed is also a substitution regex, albeit an incredibly long one. The delimiter is semi-colon.
This substitution replaces .* in $_ - the default input and pattern-searching space - with a rather large amount of punctuation characters, which represents the bulk of the code. Since .* matches any string, even the empty string, it will simply get inserted into $_, and is for all intents and purposes identical to simply assigning the string to $_, which is what I did:
$_ = q;]="&\%[=.*.,-))'-,-# .......;;
The following lines are a transliteration and another substitution. (I inserted comments to point out the delimiters)
y; -"[%-.:<-#]-`{-}#~\$\\;{\$()*.0-9\;\\_rs}&a-h;;
#^ ^ ^ ^
#1 2 3
(1,2,3 are delimiters, the semi-colon between 2 and 3 is escaped)
The basic gist of it is that various characters and ranges -" (space to double quote), and something that looks like character classes (with ranges) [%-.:<-#], but isn't, get transliterated into more legible characters e.g. curly braces, dollar sign, parentheses,0-9, etc.
s;(.*);$_;see;
The next substitution is where the magic happens. It is also a substitution with obfuscated delimiters, but with three modifers: see. s does nothing in this case, as it only allows the wildcard character . to match newline. ee means to evaluate the expression twice, however.
In order to see what I was evaluating, I performed the transliteration and printed the result. I suspect that I somewhere along the line got some characters corrupted, because there were subtle errors, but here's the short (cleaned up) version:
s;(.*);73756220656e6372797074696f6e5f6 .....;; # very long line of alphanumerics
s;(..);chr(hex($1));eg;
s;(.*);$_;see;
s;(.*);704b652318371910023c761a3618265 .....;; # another long line
s;(..);chr(hex($1));eg;
&e_echr(\$_);
s;(.*);$_;see;
The long regexes are once again the data containers, and insert data into $_ to be evaluated as code.
The s/(..)/chr(hex($1))/eg; is starting to look rather legible. It is basically reading two characters at the time from $_ and converting it from hex to corresponding character.
The next to last line &e_echr(\$_); stumped me for a while, but it is a subroutine that is defined somewhere in this evaluated code, as hobbs so aptly was able to decode. The dollar sign is prefixed by backslash, meaning it is a reference to $_: I.e. that the subroutine can change the global variable.
After quite a few evaluations, $_ is run through this subroutine, after which whatever is contained in $_ is evaluated a last time. Presumably this time executing the code. As hobbs said, a key is required, which is taken from the environment %ENV of the machine where the script runs. Which we do not have.
Ask the B::Deparse module to make it (a little more) readable.