protection racket

protection racket

[Ray Andrews]

All:

So, my command wrappers have the ability to save to history the actual 
system commands that they execute. That involves taking some command 
string and saving it to a variable, but without any expansions or 
removals of quotes and with everything being taken literally except that 
variables will be expanded.   It seems that there's no way to do this 
except by protecting various things with backslashes, and it's easy to 
understand that, eg. the pipe symbol must be backslashed so as to be 
taken as a literal character. I'm used to this, but I've tried doing it 
with a command string that involved a few 'sed's and things got out of 
control. This was the command:

     apt-cache show "$1" | egrep --color=always "^|$1" | sed -r 
'/^Package: / s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g' | sed 
's/^\(Package: .*\)$/\x1b[33;1m\1\x1b[0m/'

... it just colorizes apt-cache output with two colors, (yellow being 
applied to the "Package: ..." line) and if that color is applied to the 
line if it is already colored by egrep, you first hafta remove the 
existing codes.  More trouble than it's worth, but an interesting 
exercise anyway.  However, if I want to save that entire line for 
re-execution (which happens in '_execute' function), by trial and error 
I found that I had to backslash protect characters that never seemed to 
need it before:

     _execute apt-cache show  \"$1\" \| egrep --color=always \"^\|$1\" 
\| sed -r \'/^Package: / 
s/\\x1b\\[\([0-9]\{1,2\}(\;[0-9]\{1,2\})?\)\?[m\|K]//g\' \| sed -r 
\'s/(Package: .*)/\\x1b\[33\;1m\\1\\x1b\[0m/\'

... It seems crazy.  I know I need to protect:  |  '  "  \   ... and 
maybe one or two other characters not relevant here, but I've never 
needed to protect:  ;  (  ) { }  ... so why do I need to backslash them 
here?  Interestingly, one pair of parenthesis need protection but 
another did not.  Very strangely, if I didn't get it exactly right, it's 
not just that the command would recall improperly, but the parser itself 
complained before the string is either saved to it's variable or 
executed.  Sed seemed to voice it's displeasure at the point of saving 
the string, not at the point of trying to execute it, so it almost seems 
as it it's sed that's being troublesome, not zsh per se.   I'm betting 
that this is one of those things where I'm suffering from some deep 
misunderstanding.  It seems weird that single quoted strings sent to sed 
would not be entirely protected already, thus further backslashes would 
seen redundant.  So far, only sed has given me this level of grief.  
Might there be some simplifications?

Re: protection racket

[Ray Andrews]

On 05/02/18 01:20 PM, Ray Andrews wrote:
>
>     _execute apt-cache show  \"$1\" \| egrep --color=always \"^\|$1\" 
> \| sed -r \'/^Package: / 
> s/\\x1b\\[\([0-9]\{1,2\}(\;[0-9]\{1,2\})?\)\?[m\|K]//g\' \| sed -r 
> \'s/(Package: .*)/\\x1b\[33\;1m\\1\\x1b\[0m/\'

This solves all issues and is both robust (I think) and understandable:

     ... sed -re \''/^Package: / 
s/\x1b\[([0-9]{1,2}(;[0-9]{1,2})?)?[m\|K]//g'\' ...
^^ ^^

Outer protected single quotes go forward to sed as sed demands, but 
inner single quotes guarantee all characters between them are protected, 
one and all, but are removed as the string goes forward once they've 
done their job of protecting the string.  I'd still like to know why the 
individual characters needed protection  above, but never mind, it might 
be beyond human understanding given how loaded sed strings are with 
potentially special characters, special both to sed and/or to zsh, so 
maybe better not to even think about it when an easy solution is at hand.