I know how to add a new filetype to ack. This was answered here
For example, I added handlebars:
--type-set=hbs=.hbs
However, I am unable to add a filetype containg a dot, such as for blade
--type-set=blade=.blade.php
If I search ack div --blade then I get no results
You'll have to use ack 2.x's --type-set regex matching.
--type-set='blade:match:.blade.php$'
Look at the ack manual (ack --man) under "Defining your own types" for details.
Take a look at ack --dump to see other examples of matching.
Related
I wanted to verify a text in a webpage exist for 2 times or ‘n’ times. I have used “Page Should Contain” keyword but it says “Pass” when it identifies single occurrence. I don’t want to verify using locator.
Ex: I want to verify the text "Success" is available in a current webpage for 3 times using robot framework
Any inputs/suggesstions would be helpful.
Too bad you don't want to use a locator, as robotframework has a keyword just for that:
Xpath Should Match X Times //*[contains(., "Success")] 2
The caveat is the locator should not be prepended with xpath= - just straight expression.
The library keyword Page Should Contain does pretty much exactly that, by the way.
And if you want to find how many times the string is present in the page - easy:
${count}= Get Matching Xpath Count //*[contains(., "Success")]
And then do any kind of checks on the result, e.g.
Should Be Equal ${count} 2
I thought the problem of not using locator sounds fun (the rationale behind the requirement still unclear, yet), so another solution - look in the source yourself:
${source}= Page Source # you have the whole html of the page here
${matches}= Get Regexp Matches ${source} >.*\b(Success)\b.*<
${count}= Get Length ${matches}
The first one gets the source, the second gets all non-overlapping (separate) occurrences of the target string, when it is (hopefully) inside a tag. The third line returns the count.
Disclaimer - please don't actually do that, unless you're 100% sure of the source and the structure. Use a locator.
We have a simple search interface which calls the search:search($query-text) function. Is there a syntax to include control for wildcarding, stemming and case sensitivity within the single text string that the function accepts? I haven't been able to find anything in the MarkLogic docs.
See the $options parameter and the <term> and <term-option> constraint at https://docs.marklogic.com/search:search . There is a guide at http://developer.marklogic.com/learn/2009-07-search-api-walkthrough
and some details http://developer.marklogic.com/learn/2009-07-search-api-walkthrough#ndbba3437f320a4a4
I don't know of any existing syntax for those options, aside from the built-in behavior of turning on wildcards when a term contains '*' or '?' and turning on case-sensitivity when the term contains capital letters.
You could develop a syntax. Implementing it might involve a custom parser along the lines of https://github.com/mblakele/xqysp then feeding the resulting cts:query into search:resolve.
Piggybacking on Eric Bloch's answer... you can always dynamically construct your node based on input in the user interface.
For example, I often do this in order to separate the facet selection portion of the query from the text search portion and put the facet selection query in the additional-query element in the options node.
I have a necessity to add support for a proprietary headers that FPGA in our design inserts in incoming Ethernet frames between MAC header and payload. Obviously have to dig in tcpdump sources and libpcap, but could anybody give some hints at where exactly to start, so that I could save time?
The first thing you need to do is to get a DLT_/LINKTYPE_ value for your proprietary headers. See the link-layer header types page on the tcpdump.org Web site for the existing DLT_/LINKTYPE_ link-layer header type values and information on how to either use one of the DLT_USERn values internally or get a new value assigned if you plan to have people outside your organization use this.
Once you have the value assigned, you'll have to do some work on libpcap:
If you've been assigned a DLT_ value, you'll have to modify the pcap/pcap.h file to add that link-layer type (and change the DLT_MATCHING_MAX value in that header file, and LINKTYPE_MATCHING_MAX in pcap-common.c, so that they are >= your DLT_ value), or wait for whoever at tcpdump.org (which will probably be me) assigns your DLT_ value and updates the libpcap Git repository (at which point you could use top-of-trunk libpcap).
If you plan to do live capturing, you may have to add a module to libpcap to support live capturing on your hardware, or, if your device looks like a regular networking device to your OS, so that you can use its native capture mechanism, modify the module for that OS to map whatever link-layer header type value the OS uses (e.g., a DLT_ value on *BSD/OS X or an ARPHRD_ value on Linux) to whatever DLT_ you're using for your link-layer header type.
You'd have to modify gencode.c to be able to compile capture filters for your DLT_ value.
Once that's done, libpcap should now work.
Now, for tcpdump:
Add an if_print routine that processes the proprietary headers (whether it just skips them or prints things for them), calls ether_print(), and then returns the sum of the length of your proprietary headers and the Ethernet header (ETHER_HDRLEN as defined in ether.h). See ether_if_print() in print-ether.c for an example.
Add a declaration of that routine to interface.h and netdissect.h, and add an entry for it, with the routine name and DLT_, to ndo_printers[] if you copied ether_if_print() (which you should) or to printers[] if you didn't (if you didn't, you'll have to pass &gndo as the first argument to ether_print()). Those arrays are in tcpdump.c.
I can see the technology-independent Tridion Content Delivery Language (TCDL) link has the following parameters, which are pretty well described on SDL Live Content.
type
origin
destination
templateURI
linkAttributes
textOnFail
addAnchor
VariantId
How do we add multiple attribute-value pairs for the linkAttributes? Specifically, what do we use to escape the double quotes as well as separate pairs (e.g. if we need class="someclass" and onclick="someevent").
The separate pairs are just space delimited, like a normal series of attributes. Try XML encoding the value of linkAttributes however. So, " become "e;, etc...
If you are using some Javascript, you might take care of the Javascript quotes too, as in \".
Edit: after I figured out your real question, the answer is a lot simpler:
You should wrap the values inside your linkAttributes in single quotes. Spaces inside linkAttributes are typically handled fine; but if not, escape then with %20.
If you need something more or want something that isn't handled by the standard tcdl:ComponentLink, remember that you can always create your own TCDL tag and and use a TagHandler or TagRenderer (look them up in the docs for examples or search for Jaime's article on TagRenderer) to do precisely what you want.
My original answer was to a question you didn't ask: what is the format for TCDL tags (in general). But the explanation might still be useful to some, so remains below.
I'd suggest having a look at what format the default building blocks (e.g. the Link Resolver TBB in the Default Finish Actions) output and use that as a guide line.
This is what I could quickly get from the transport package of a published page:
<tcdl:Link type="Page" origin="tcm:5-199-64" destination="tcm:5-206-64"
templateURI="tcm:0-0-0" linkAttributes="" textOnFail="true"
addAnchor="" variantId="">Home</tcdl:Link>
<tcdl:ComponentPresentation type="Embedded" componentURI="tcm:5-69"
templateURI="tcm:5-133-32">
<span>
...
One of the things that I know from experience: your entire TCDL tag will have to be on a single line (I wrapped the lines above for readability only). Or at least that is the case if it is used to invoke a REL TagRenderer. Clearly the tcdl:ComponentPresentation tag above will span multiple lines, so that "single line rule" doesn't apply everywhere.
And that is probably the best advice: given the fact that TCDL tags are processed at multiple points in Tridion Publishing, Deployment and Delivery pipeline, I'd stick to the format that the default TBBs output. And from my sample that seems to be: put everything on a single line and wrap the values in (double) quotes.
I need to allow the user to submit queries as follows;
/search/"my search string"
but it's failing because of request validation, as outlined in the following 2 questions:
How to include quote characters as a route parameter? Getting "Illegal characters in path" message
How to modify request validation?
I'm currently trying to figure out how to disable request validation for the quote character, but i'd like to know the risks before I actually put the site live with this disabled? I will not disable the request validation unless I can only disable it for the quote character, so I do intend to disallow every other character that's currently not allowed.
According to the URI generic syntax specification (RFC 2396), the double-quote character is explicitly excluded and must be escaped (i.e. %22). See section 2.4.3. The reason given in the spec:
The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields.
You can see easily why this is the case -- imagine trying to create a link in HTML to your URL:
<a href="http://somesite/search/"my search string""/>
That would fail HTML parsing (and also breaks SO's syntax highlighting). You also would have trouble doing basic things with the URL like emailing it to someone (the email client wouldn't parse the URL correctly), posting it on a message board, sending it in an instant message, etc.
For what it's worth, spaces are also explicitly excluded (same section of the RFC explains why).