I think sec special characters can all be escaped. For example, percent
sign can be escaped with another %, so 'write - %%a' action will print the
string "%a" to standard output (the same strategy can be used for $ that
starts a match variable reference). Another frequently occurring issue is
related to the use of semicolon within an action, since semicolon is also
used as a separator between actions. To mask such a semicolon, the relevant
part of the action list must be enclosed in parentheses, for example
'shellcmd (pwd; ls -l)'.
As for now, it looks to me that the variables would be most useful for
accessing characters without a printable representation. Even if some
scenarios would surface in the future for printable characters, they can be
added to the existing variable scheme. Also, users can quite easily assign
them to their own variables (like with 'lcall %A -> ( sub { chr(65) } )'
which sets %A variable to "A" letter). So if a printable character is
needed on a rare occasion, there is a way set a custom variable manually.
kind regards,
risto
2016-04-18 23:05 GMT+03:00 David Lang <da...@lang.hm>:
> On Mon, 18 Apr 2016, Risto Vaarandi wrote:
>
> hi David,
>> I think I misread your previous mail -- my apologies. You were talking
>> about the variables holding control characters, and *not* unpadded
>> time-based variables?
>>
>
> Yes, I was saying we should add variables for all the control characters
> if we think we need them (although most should be able to be entered with
> normal perl escaping rules)
>
> do we need variables for characters that are considered special by SEC?
> (quotes, semicolens, percent, etc?) does it make sense to just define the
> entire ascii set?
>
> David Lang
>
>
> If so, it is indeed easy to add support for them.
>> Once initialized, they don't need updates like time-based variables, so
>> coding them in doesn't require much effort.
>> kind regards,
>> risto
>>
>>
>>
>> (It is quite easy to extend this set with all special characters ASCII
>>>> 0-31
>>>> by a simple naming convention %.asc<N>, but I am not sure if there is
>>>> any
>>>> practical need for this.)
>>>>
>>>>
>>> I think we may as well add them in. I know I've run across a few oddities
>>> and it seems better to add them all than to play wack-a-mole on them over
>>> time.
>>>
>>> As for the other variables, they seem to cover things, but I wish there
>>> was a good way to not have three versions of everything. But I guess that
>>> would require having a function to cast them from one class to another
>>> :-(
>>>
>>> David Lang
>>>
>>>
>>>
>>>
>>>
>>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
