How to apply and override preferences with tshark? - linux

I am writing a plugin for wireshark-1.9.2. We do not have GUI on the server, so we use tshark. My question is how to add and apply new preferences with tshark?
My $HOME/.wireshark/preferences file contains only one line:
ls_payload_display_len: 20
When I run tshark, I get a warning:
Syntax error in preference ls_payload_display_len (applying your preferences once should remove this warning)
I can access the value of the preference in the dissector code with function prefs_register_uint_preference(...). But I cannot override it with the -o option when start tshark:
tshark: Invalid -o flag "ls_payload_display_len:80"
So, the two questions are:
How do I apply my preferences file with tshark, so that the syntax error warning won't show again?
How do I override preferences values with the -o option of tshark?
Thanks.

It appears that for an attempt to set a non-existent preference, Wireshark and TShark don't report it as a non-existent preference, they report it as a "Syntax error in preference" in the preferences file and as an "Invalid -o flag" on the command line.
prefs_register_uint_preference() takes, as its first argument, a pointer to a module_t, so you must have referenced a preferences module. The prefs_register_module() call takes a name argument, so the module has a name; the full name for your preference includes the module name, so, if your preference module's name is "my_protocol", your preference's name would be "my_protocol.ls_payload_display_len", and you would have to use that full name in the preferences file and on the command line, e.g.
my_protocol.ls_payload_display_len: 20
and
tshark -o my_protocol.ls_payload_display_len:80

Related

openSMILE: Trying to Extract emotion features from emobase.conf results in error

I was going through the openSMILE book and in section 2.5.6, it mentioned that in order to extract emotion features, one needs to run a command of this sort:
SMILExtract_Release -C config/emobase.conf -I input.wav -O angers.arff -instname ANGER -classes {anger,fear,disgust} -classlabel anger
However, running this command gives an error:
(ERROR) [0] in commandlineParser : doParse: unknown option '-instname' on commandline!
Wanted to know how to fix this. Is -instname a deprecated option? If so, what should it be replaced with?
This is happening because config/emobase.conf doesn't have a definition for instname in the arrfsink component.
openSMILE allows to define new command line options for the openSMILE binary directly in the configuration file. If you want to define this parameter your config file must have a line like this:
instanceName=\cm[instname(N){unknown}:instance name]
You can run opensmile-2.3.0/SMILExtract -h to see which CMD options are available regardless of the configuration file. Other CMD parameters such as -instname should be defined in the configfile. Please check "config\shared\standard_data_output.conf.inc" for an example o how to define this command line option for your configuration file.

add a permitted path to ghostscipt running configuration

I use a program which create me postscript file before using ps2pdf to make it a readable pdf, i've made a program which add some string to overwrite the company new logo. (The first program can't import image file itself).
I add the string before the before-last line of the file (" showpage").
While running my program to add the logo there is no error.
With the option -dNOSAFER everything is fine, but by default it's set to -dSAFER, and an invalidfileaccess error pop, the files are 6 jpg images alone in their directory.
I don't want to make it run with the -dNOSAFER option on. As it will fully open the file system.
In the documentation I've seen that there is a "permitted path" setting, but i can't find nowhere to set this up. Is it just a command line option to set in the command launching the program ? Or is there a config file for GhostScript / ps2pdf where i can put the path to this directory as permitted path.
in this documentation :
http://www.ghostscript.com/doc/current/Use.htm
I only find
-dTTYPAUSE
Causes Ghostscript to read a character from /dev/tty, rather than
standard input, at the end of each page. This may be useful if input
is coming from a pipe. Note that -dTTYPAUSE overrides -dNOPAUSE. Also
note that -dTTYPAUSE requires opening the terminal device directly,
and may cause problems in combination with -dSAFER. Permission errors
can be avoided by adding the device to the permitted reading list
before invoking safer mode
gs -dTTYPAUSE -dDELAYSAFER -c '<< /PermitFileReading [ (/dev/tty)] >> setuserparams .locksafe' -dSAFER
The quote is just for the context but is this a way to put the permitted path ?
As gs automatically launch with the full system as readOnly there will be no difference ? There is no other find result for PermitFile in this page.
Try adding the required path to the search path with -I (Include) See Use.htm, section 8 How Ghostscript finds files. This should only be a problem if you are using 'run' or similar to read files from another location.
The section on TTYPAUSE is not relevant.

Turn off terminal entry line prefix/header

How do I fix this? I don't want to change my server name I just want to customize the text here (no server name, still shows path/user). Also what's this section of the terminal window called?
The Terminal Entry line prefix is called the shell prompt.
You can generally find the current config by typing
echo $PS1
That returned this for me: [\e]0;\u#^C\w\a]${debian_chroot:+($debian_chroot)}\u#\h:\w\$
So I was able to remove the "#\h" in both locations and get the desired tag.
export PS1="\[\e]0;\u: \w\a\]${debian_chroot:+($debian_chroot)}\u:\w\$ "
leaving me with "root:/kliq$'

Why am I getting a syntax near unexpected token newline error?

I am trying to create a .bashrc file with the android dev kit in Ubuntu. Only problem is, when i edit/ add to the bashrc file, I get a "syntax error near unexpected token newline". I posted the code where the error is, specifially between android SDK home token and android NDK token. Thanks for the help
#Android SDK Home
export ANDROID_SDK=</Documents/adt-bundle-linux-x86_64-20140702>
#ANDROID NDK Home
export NDK=~/android-ndk-r10b
export PATH=$PATH: $ANDROID_SDK/tools:$ANDROID_SDK/platform-tools
I guess that you have read something like this in a guide somewhere:
Add the following lines to your .bashrc file:
export ANDROID_SDK=<path/to/your/SDK>
# etc.
The < > are meant as placeholders, i.e. <replace this bit>. You don't need to put the path inside them, in fact you should remove them, as they are invalid syntax (which is causing the error you mention). Also, you should remove the space between $PATH: $ANDROID_SDK later on:
#Android SDK Home
export ANDROID_SDK="/Documents/adt-bundle-linux-x86_64-20140702"
#ANDROID NDK Home
export NDK="$HOME/android-ndk-r10b"
export PATH="$PATH:$ANDROID_SDK/tools:$ANDROID_SDK/platform-tools"
To be more specific, the error was caused by the > at the end of the export line, as this means "redirect the output of the command to the following file descriptor". Bash is then expecting the name of a file descriptor but all it found was a newline. The < at the beginning is also problematic, as it means "redirect the contents of this file descriptor to the command", which won't do anything useful in your case. See this wiki page for more details.
By the way, there's no harm in using double quotes, in fact, they're encouraged. Using them means that word splitting will not occur in case the name of a directory contains a space. I've added some around your assignments and changed ~ to $HOME, so that it will still do what you want (the ~ will be interpreted literally within double quotes, whereas $HOME will expand to the path of your home directory).
Angle brackets are not valid to use this way.

scons surrounds option with double quotes

I use scons (V1.1.0) for a project that contains a build step that involves the flex tool.
The definition for the flex command in the scons default rules is:
env["LEX"] = env.Detect("flex") or "lex"
env["LEXFLAGS"] = SCons.Util.CLVar("")
env["LEXCOM"] = "$LEX $LEXFLAGS -t $SOURCES > $TARGET"
which I don't want to change.
However, since -t causes #line directives to be created in the output file that refer to the file "<stdout>", this confuses the subsequent gcov processing.
As a solution, I found that -o can be used to override the file name flex produces into the #line directives (it still produces its output on stdout due to the -t option which apparently has precedence).
To achieve that, I added this in the project's SConscript file:
env.AppendUnique(LEXFLAGS = ['-o $TARGET','-c'],delete_existing=1)
I added the -c option (which does nothing) only to show the difference between how it is treated compared to -o.
An according debug print in the SConscript file results in the following (as expected):
repr(env["LEXFLAGS"]) = ['-o $TARGET', '-c']
This results in the following command line, according to the scons log:
flex "-o build/myfile.cpp" -c -t src/myfile.ll > build/myfile.cpp
So the -c option gets into the command line as desired, but the -o option and its filename parameter has double quotes around it, that must have been created by scons when expanding the LEXFLAGS variable.
When I use this definition for LEXFLAGS instead:
env.AppendUnique(LEXFLAGS = ['--outfile=$TARGET','-c'],delete_existing=1)
the resulting command line works as desired:
flex --outfile=build/myfile.cpp -c -t src/myfile.ll > build/myfile.cpp
So one could speculate that the blank in the -o case caused the double quotes to be used, maybe in an attempt to bind the content together into one logical parameter for the command.
So while my immediate problem is solved by using --outfile, my question is still is it possible to rid of the double quotes in the -o case?
Thanks,
Andy
SCons 1.1.0 is extremely old at this point. I'd recommend trying 2.3.0. But your analysis is correct; if an option (a single option, that is) has a space in it, SCons will quote it so it stays a single option. But you don't have a single option; you really have two, '-o' and '$TARGET'. Just break it up like that and it'll work.

Resources