I have a set of instructions, for example Linux's "ls", "grep", "cd", etc.
I want the user to be able to execute this commands without knowing the exact names and parameters but rather with something similar to their meaning in plain English, e.g. "show me all folders", "filter all files by name" , "go to directory". Or in other words: the user input is "Show me all files and then show me all that contains 'foo' " to be translated to "ls | grep foo"
I understand that I will need some kind of meta-information about each instruction and do some kind of evaluation how close is the user query term to each instruction. Something like:
<instruction>
<command>ls</command>
<semantic>lists all files</semantic>
<plainEnglish>List all the files in this directory</plainEnglish>
<synonyms>
<synonym>Show all files</synonym>
...etc
</synonyms>
</instruction>
So which is the important information and how to do this evaluation?
Any general guidelines how I can translate the user's input to a specific instruction from my set? (This sounds like quite a challenge to me)
Related
question：
CrackMe1 is an ELF executable that can be executed independently in Android.
Execute CrackMe1 program in shell and prompt "Input Your Answer"
Input the correct string, press enter, if the program output "True Answer", it means yes, output "Wrong Answer", it means failure
What I need to do is reverse analyze the ELF file and find the correct string to be entered (which can be understood as password here).
I use IDA to decompile but find no string matching information in the decompiled result
Here is the code of the decompiled main function
I would like to ask what method can be used to find the string to be entered for the above situation.
It can be a tutorial or a specific example
file： https://pan.baidu.com/s/1Tfbtk792UgYLj9XxUmb8yg?pwd=49ff
passwd：49ff
SYNOPSIS
From man(1):
-l
Format and display local manual files instead of
searching through the system's manual collection.
-t
Use groff -mandoc to format the manual page to stdout.
From groff_tmac(5):
papersize
This macro file is already loaded at start-up by troff so it
isn't necessary to call it explicitly. It provides an interface
to set the paper size on the command line with the option
-dpaper=size. Possible values for size are the same as
the predefined papersize values in the DESC file (only
lowercase; see groff_font(5) for more) except a7–d7.
An appended l (ell) character denotes landscape orientation.
Examples: a4, c3l, letterl.
Most output drivers need additional command-line switches -p
and -l to override the default paper length and orientation
as set in the driver-specific DESC file. For example, use the
following for PS output on A4 paper in landscape orientation:
sh# groff -Tps -dpaper=a4l -P-pa4 -P-l -ms foo.ms > foo.ps
THE PROBLEM
I would like to use these to format local and system man pages to print out, but want to switch the paper size from letter to A4. Unfortunately I couldn't find anything in man(1) about passing options to the underlying roff formatter.
Right now I can use
zcat `man -w man` | groff -tman -dpaper=a4 -P-pa4
to format man(1) on stdout, but that's kind of long and I'd rather have man build the pipeline for me if I can. In addition the above pipeline might need changing for more complicated man pages, and while I could use grog, even it doesn't detect things like accented characters (for groff's -k option), while man does (perhaps using locale settings).
The man command is typically intended only for searching for and displaying manual pages on a TTY device, not for producing typeset and paper printed output.
Depending on the host system, and/or the programs of interest, the a fully typeset printable form of a manual page can sometimes be generated when a program (or the whole system) is compiled. This is more common for system documents and less common for manual pages though.
Note that depending on which manual pages you are trying to print there may be additional steps required. Traditionally the following pipeline would be used to cover all the bases:
grap $MANFILE | pic | tbl | eqn /usr/pub/eqnchar | troff -tman -Tps | lpr -Pps
Your best solution for simplifying your command line would probably be to write a little tiny script which encapsulates what you're doing. Note that man -w might find several different filenames, so you would probably want to print each separately (or maybe only print the first one).
The goal is:
Control smart house via predefined text commands. Without any activation word like okay google, it always listening.
What's done:
pocketsphinx_continuous -inmic yes -hmm /path/zero_ru.cd_cont_4000 -dict /path/my_dictionary_out -lm /path/lmbase.lm.DMP
Where my_dictionary_out has using words one by one. And it works, but I think KWS mode might be better. So I've written a text file like:
включи свет комнате /1e-50/
выключи свет комнате /1e-50/
and trying to run sphinx without language model (-lm option), but got nothing. It doesn't recognize commands from keywords file.
What's wrong?
I need an application that prints/visualizes input/output pairs during the FST runs. I mean, for each state of the fst, it needs to print out a tuple that contains input for that state and output of the state. Right now I can generate fst files that is compatible with foma,hfst and xfst fst tools. So, I guess the visualization tool I need should be enough to compatible with any of them. Is there anyone who knows such a tool ?
foma can produce dot format files that can be visualized by graphviz. On Debian/Ubuntu, install graphviz with
$ sudo apt-get install graphviz
foma can read att format files (produced with hfst-fst2txt for anything HFST can read, or lt-print for anything from lttoolbox); assuming you've got such a file named myfst.att, you can do
$ foma
foma[0]: read att myfst.att
foma[1]: view
to display the full FST. That will show each input/output pair on each edge between states of the FST.
But you say "during runs" – are you talking about also showing the queue of "live states"? If so, I don't know of a tool that does this, that would be nice! One thing you could do is to modify the HFST source to output the list of live states and string vectors as it's processing, and then combine that with the dot file to e.g. colour in the live states. (If so, you may want to take this to the #hfst channel on irc.freenode.net.)
There is also a script att2dot.py on https://ftyers.github.io/2017-%D0%9A%D0%9B_%D0%9C%D0%9A%D0%9B/hfst.html that can be used on the command line like
hfst-fst2txt chv.lexc.hfst | python3 att2dot.py | dot -Tpng -ochv.lexc.png if you prefer something more scriptable. If you use that from the Python library of HFST, you might be able to get the "live states" for every part of an analysis more easily.
I have a little command line tool (written in Objective C, runs under MacOS) that tracks changes to folders and applies rules to files. This tool also informs the user about the progress. It says like:
"Found 3 files of type Z and applied rule"
"Found 6 files of typ x and applied rules"
Currently, the tool outputs the feedback as an endless list but this does not look very handy. What I'm after is a solution to only type the line per file type once and then update the number in the terminal if the tool finds another file of that type. Very similar to how "top" under Unix gives the feedback.
However, to do so, I'll need to move the cursor in the terminal backwards to the beginning of the line and also one or multiple lines backwards.
Is this possible and does anybody know, how to do so?
Thanks
Norbert