[ILUG] Another Scripting Question...

[Brian Foster]

  | Date: Sat, 30 Jul 2005 10:52:52 +0100
  | From: Michael Armbrecht <michael.armbrecht at gmail.com>
  | 
  | On 30/07/05, Brian Foster <blf at blf.utvinternet.ie> wrote:
  |  >  | From: Michael Armbrecht <michael.armbrecht at gmail.com>
  |  >  | Date: Fri, 29 Jul 2005 12:23:50 +0100
  |  >  |
  |  >  |  sed -e 's/notify yes;/notify no; \x0A masters { $IP;}/'
  |  >
  |  > interesting!
  |  > that does seem to work (with GNU sed(1) anyways),
  |  > albeit I've never(?) before either seen, or seen
  |  > documented, the `\x' replacement-escape.  [ ... ]
  | 
  | Could it be that it's not a sed replacement escape but just a standard
  | way to include the hex code into a string; ie. \x for hex, \0 for
  | octal etc -- non?  At least the echo man page was where I got the idea
  | from...

 good thinking.  that idea is plausible, and (almost)
 is what could be happening, but no.  the \xHH must
 be handled by sed(1) itself.

 the only other sensible candidate (in this example)
 is bash(1).  there are two problems with the theory
 `bash' is translating \x0A to a newline:

 1st, the above uses 'single'-quotes, meaning what
      is quoted is 100% literal.  as the bash(1)
      man(1) page (version GNU Bash-2.05b) says:

        “Enclosing characters in single quotes preserves the
         literal value of each character within the quotes.”

      an _enormous_ number of shell scripts would
      break if _anything_ inside 'single'-quotes
      was ever taken not-literally.

 2nd, if `bash' was nonetheless doing the translation,
      you would get an error from `sed' because the
      command would then be illegal, which was (in part)
      the original problem:

         $ #chars: 1234567890123456789012345
         $ sed -e 's/notify yes;/notify no; 
         masters { $IP;}/'
         sed: -e expression #1, char 25: Unterminated `s' command
         $ 

      (to preserve identicalness to the above `sed',
      there is a space before the newline, which is
      why the error says char 25 rather than 24.)

 the interesting thing is `bash' _does_ support the
 \xHH escape, but only in a special situation which
 is not used in the `sed' example.

 the \xHH `bash' escape is (AFAIK) a GNU(-only?)
 extension.  to preserve compatibility with other
 Bourne-ish shells (very important!), \xHH is only
 recognised in an extended syntax (not likely to
 be found in older scripts).  from the man page:

   “Words of the form $'string' are treated specially.  The
    word expands to string, with backslash-escaped characters
    replaced as specified by the ANSI C standard.  [ ... ]:
       \xHH   The eight-bit character whose value is the
              hexadecimal value HH (one or two hex digits)”

 (b.t.w., there are some `bash' \-escapes, elucidated
 from the above quote, such as \cX, which are not in
 any ANSI/ISO C standard, so in a pedantic sense the
 man page is misleading.)

 try using $'...' in the above `sed' example, and as
 per reason 2, you get the expected error from `sed':

    $ sed -e $'s/notify yes;/notify no; \x0A masters { $IP;}/'
    sed: -e expression #1, char 25: Unterminated `s' command
    $ 

 ergo, we can conclude that for above `sed' example,
 it must be `sed' itself which is handling the \xHH
 escape.  the only other candidate is `bash', but as
 argued above, `bash' is clearly not the culprit.

cheers!
	-blf-

p.s.  IMHO, the $'...' does not look well thought out.
      it is not UCS/Unicode (albeit C99s \uHHHH could
      be added?); it only works as a word (awkward!);
      the result is 'single'-quoted (obnoxious); and
      $"..." means something entirely different.  ;-(

-- 
Experienced (20+ yrs) kernel/software Eng: | Brian Foster   Montpellier,
 • Unix, embedded, &tc;  • Linux;  • doc;  | blf at utvinternet.ie   FRANCE
 • IDL, automated testing, process, &tc.   |  Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie  |     http://www.stopesso.com