Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #1870 > unrolled thread

Regexp expression that selects PostScript strings

Back to article view | Back to comp.lang.postscript

Contents

  Regexp expression that selects PostScript strings jdaw1 <jdawiseman@gmail.com> - 2014-05-03 13:50 -0700
    Re: Regexp expression that selects PostScript strings tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-05-03 20:52 -0400
      Re: Regexp expression that selects PostScript strings luser- -droog <mijoryx@yahoo.com> - 2014-05-03 21:42 -0700
        Re: Regexp expression that selects PostScript strings luser- -droog <mijoryx@yahoo.com> - 2014-05-04 00:07 -0700
        Re: Regexp expression that selects PostScript strings jdaw1 <jdawiseman@gmail.com> - 2014-05-04 07:48 -0700
    Re: Regexp expression that selects PostScript strings jdaw1 <jdawiseman@gmail.com> - 2014-05-05 08:48 -0700
      Re: Regexp expression that selects PostScript strings jdaw1 <jdawiseman@gmail.com> - 2014-05-05 08:58 -0700
        Re: Regexp expression that selects PostScript strings luser- -droog <mijoryx@yahoo.com> - 2014-05-06 09:58 -0700

#1870 — Regexp expression that selects PostScript strings

Does anybody have to hand a regexp expression that selects PostScript strings?

As a simple non-example, \([^\)]*\) fails to cope with the likes of 

    (and (as an aside) this should be mentioned)

and also with strings containing \( or \).

[toc] | [next] | [standalone]

#1871

On Sat, 3 May 2014 13:50:42 -0700 (PDT), jdaw1 wrote:

> Does anybody have to hand a regexp expression that selects PostScript strings?
> 
> As a simple non-example, \([^\)]*\) fails to cope with the likes of 
> 
>     (and (as an aside) this should be mentioned)
> 
> and also with strings containing \( or \).

Why would you have expected it to cope with the likes of that?
What it seems designed to  cope with is the likes of this:

:  (and )as an aside) this should be mentioned)

HTH. Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#1873

On Saturday, May 3, 2014 7:52:38 PM UTC-5, tlvp wrote:
> On Sat, 3 May 2014 13:50:42 -0700 (PDT), jdaw1 wrote:
> 
> > Does anybody have to hand a regexp expression that selects PostScript strings?
> > 
> > As a simple non-example, \([^\)]*\) fails to cope with the likes of 
> > 
> >     (and (as an aside) this should be mentioned)
> > 
> > and also with strings containing \( or \).
> 
> Why would you have expected it to cope with the likes of that?
> What it seems designed to  cope with is the likes of this:
> 
> :  (and )as an aside) this should be mentioned)
> 

Not sure about the example, but I think in general
regular expressions cannot handle postscript strings
because of the possibility of nested un-escaped parens.

[toc] | [prev] | [next] | [standalone]

#1874

On Saturday, May 3, 2014 11:42:33 PM UTC-5, luser- -droog wrote:
> On Saturday, May 3, 2014 7:52:38 PM UTC-5, tlvp wrote:
> 
> > On Sat, 3 May 2014 13:50:42 -0700 (PDT), jdaw1 wrote:
> 
> > 
> > > Does anybody have to hand a regexp expression that selects PostScript strings?
> > > 
> > > As a simple non-example, \([^\)]*\) fails to cope with the likes of 
> > > 
> > >     (and (as an aside) this should be mentioned)
> > > 
> > > and also with strings containing \( or \).
> > 
> > Why would you have expected it to cope with the likes of that?
> > What it seems designed to  cope with is the likes of this:
> > 
> > :  (and )as an aside) this should be mentioned)
> > 
> 
> Not sure about the example, but I think in general
> regular expressions cannot handle postscript strings
> because of the possibility of nested un-escaped parens.

My own code for validating a postscript "statement" 
containing complete but arbitrarily nested parens,
braces, and angle-brackets, is a push-down automaton,
the next class up from the finite-automata that can
process regular expressions.

http://code.google.com/p/xpost/source/browse/src/lib/xpost_file.c#198
/* pinch-off a tmpfile containing one "statement" from file. */
 
/*@null@*/
 
static
 
int statementedit(FILE *in, FILE **out)
 
{
 
    FILE *fp;
 
    int c;
 
    char nest[MAXNEST] = {0}; /* any of {(< waiting for matching >)} */
 
    int defer = -1; /* defer is a flag (-1 == false)
 
                       and an index into nest[] */
 

 
    c = fgetc(in);
 
    if (c == EOF)
 
    {
 
        return undefinedfilename;
 
    }
 
#ifdef DEBUG_FILE
 
        printf("tmpfile (fdopen)\n");
 
#endif
 
    fp = f_tmpfile();
 
    if (fp == NULL) {
 
        XPOST_LOG_ERR("tmpfile() returned NULL");
 
        return ioerror;
 
    }
 
    do {
 
        if (defer > -1) {
 
            if (defer > MAXNEST)
 
            {
 
                return syntaxerror;
 
            }
 
            switch(nest[defer]) { /* what's the innermost nest? */
 
            case '{': /* within a proc, can end proc or begin proc, string, hex */
 
                switch (c) {
 
                case '}': --defer; break;
 
                case '{':
 
                case '(':
 
                case '<': nest[++defer] = c; break;
 
                } break;
 
            case '(': /* within a string, can begin or end nested paren */
 
                switch (c) {
 
                case ')': --defer; break;
 
                case '(': nest[++defer] = c; break;
 
                case '\\': fputc(c, fp);
 
                           c = fgetc(in);
 
                           if (c == EOF) goto done;
 
                           goto next;
 
                } break;
 
            case '<': /* hexstrings don't nest, can only end it */
 
                if (c == '>') --defer; break;
 
            }
 
        } else switch (c) { /* undefined, can begin any structure */
 
        case '{':
 
        case '(':
 
        case '<': nest[++defer] = c; break;
 
        case '\\': fputc(c, fp);
 
                   c = fgetc(in); break;
 
        }
 
        if (c == '\n') {
 
            if (defer == -1) goto done;
 
            { /* sub-prompt */
 
                int i;
 
                for (i=0; i <= defer; i++)
 
                    putchar(nest[i]);
 
                fputs(".:", stdout);
 
                fflush(NULL);
 
            }
 
        }
 
next:
 
        fputc(c, fp);
 
        c = fgetc(in);
 
    } while(c != EOF);
 
done:
 
    fseek(fp, 0, SEEK_SET);
 
    //return fp;
 
    *out = fp;
 
    return 0;
 
}
 

[toc] | [prev] | [next] | [standalone]

#1875

> Why would you have expected it to cope with the likes of that?

I didn't. It was a simple example of a candidate string finder that works often but not always.



> Not sure about the example, but I think in general
> regular expressions cannot handle postscript strings
> because of the possibility of nested un-escaped parens.

The existence of 
http://www.regular-expressions.info/balancing.html 
led me to hope that a regexp suitable for my text editor was possible. Perhaps, I hoped, an expert has already done the work. 



But seemingly not. I need to read a manual. Regexp would be a good thing to learn anyway.

[toc] | [prev] | [next] | [standalone]

#1882

Progress. 

\((\\\)|\\\(|[^\)\(])*\)
finds strings containing escaped parentheses. But what if the string contains a parenthetical aside?

(\((\\\)|\\\(|[^\)\(])*\((\\\)|\\\(|[^\)\(])*\)(\\\)|\\\(|[^\)\(])*\))|(\((\\\)|\\\(|[^\)\(])*\))
finds strings containing escaped parentheses, and some parenthetical asides, albeit non-nested asides. That is nearly good enough for me -- I just need to understand how to allow newlines inside the string.

And regexp is becoming the least-legible computer language yet tried by me.

[toc] | [prev] | [next] | [standalone]

#1883

Oh no. As well as being illegible, regexp is inconsistent. The above doesn't work in my preferred PostScript text editor, Alpha X, but does work in TextMate. Sigh.

[toc] | [prev] | [next] | [standalone]

#1886

On Monday, May 5, 2014 10:58:17 AM UTC-5, jdaw1 wrote:
> Oh no. As well as being illegible, regexp is inconsistent. The above doesn't work in my preferred PostScript text editor, Alpha X, but does work in TextMate. Sigh.

Yes, different regexp implementations will tend to use different
metacharacters, different escaping rules, and different extensions.

I stand by my earlier claim "regular expressions are not powerful 
enough to describe balanced, nested constructs (like parens)". 
But, as you've shown there are options.

Some "regexp" packages offer extra capabilities by not actually
doing *regular expressions* (in the computer science sense).

Or, as you've shown, you can expand-out a few cases and handle
nesting up to a certain level. If the regexp package lets you
quantify over the star or plus (discover the number of repetitions),
then you can represent "a^nb^m" and check that n==m later, in the
host program.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web