crm114(1)

πŸ“¦ in ubuntu stonking

🌸 NAME 🌸

okay bestie, meet crm114 β€” aka The Controllable Regex Mutilator πŸ’… (yep, that's crm114(1) if you're being all formal about it).


✨ SYNOPSIS ✨

crm114 [OPTION]... CRMFILE

🚨 WARNING, READ THIS ONE πŸ’€

This man page is taken from an older CRM114 version. It's here as a lil convenience for Debian users and may not be up-to-date. If you wanna update it, please send appropriate patches to the Debian bug tracking system. 🫢


πŸ’… OPTIONS πŸ’…

okay so here's the whole flag menu, no skips, no shortcuts, we eat the entire thing:

  • -d N β€” enter debugger after running N cycles. Omitting N means N equals 0.
  • -e β€” do not import any environment variables.
  • -h β€” print help text.
  • -p β€” generate an execution-time-spent profile on exit.
  • -P N β€” max program lines.
  • -q m β€” mathmode (0,1 = alg/RPN only in EVAL, 2,3 = alg/RPN everywhere).
  • -s N β€” new feature file (.css) size is N (default 1 meg+1 featureslots).
  • -S N β€” new feature file (.css) size is N rounded to 2^I+1 featureslots.
  • -t β€” user trace output.
  • -T β€” implementors trace output (only for the masochistic!).
  • -u dir β€” chdir to directory dir before starting execution.
  • -v β€” print CRM114 version identification and exit.
  • -w N β€” max data window (bytes, default 16 megs).
  • -- β€” signals the end CRM114 flags; prior flags are not seen by the user program; subsequent args are not processed by CRM114.
  • --foo β€” creates the user variable :foo: with the value SET.
  • --x=y β€” creates the user variable :x: with the value y.
  • -{ stmts} β€” execute the statements inside the {} brackets.
  • crmfile β€” (.crm file name).

πŸ¦‹ DESCRIPTION πŸ¦‹

CRM114 is a language designed to write filters in. It caters to filtering email, system log streams, html, and other marginally human-readable ASCII that may occasion to grace your computer. πŸ’Œ

CRM114's unique strengths are the data structure (everything is a string and a string can overlap another string), it's ability to work on truly infinitely long input streams, it's ability to use extremely advanced classifiers to sort text, and the ability to do approximate regular expressions (that is, regexes that don't quite match) via the TRE regex library. iconic behavior tbh ✨

CRM114 also sports a very powerful subprocess control facility, and a unique syntax and program structure that puts the fun back in programming (OK, you can run away screaming now πŸ™ˆ). The syntax is declensional rather than positional; the type of quote marks around an argument determine what that argument will be used for.

The typical CRM114 program uses regex operations more often than addition (in fact, math was only added to TRE in the waning days of 2003, well after CRM114 had been in daily use for over a year and a half). πŸ•°οΈ

In other words, crm114 is a very very powerful mutagenic filter that happens to be a programming language as well.

The filtering style of the CRM-114 discriminator is based on the fact that most spam, normal log file messages, or other uninteresting data is easily categorized by a few characteristic patterns (such as "Mortgage leads", "advertise on the internet", and "mail-order toner cartridges".) CRM114 may also be useful to folks who are on multiple interlocking mailing lists. πŸ’€

In a bow to Unix-style flexibility, by default CRM114 reads it's input from standard input, and by default sends it's output to standard output. Note that the default action has a zero-length output. Redirection and use of other input or output files is possible, as well as the use of windowing, either delimiter-based or time-based, for real-time continuous applications. πŸŒ€

CRM114 can be used for other than mail filtering; consider it to be a version of grep with super powers. If perl is a seventy-bladed swiss army knife, CRM114 is a razor-sharp katana that can talk. πŸ—‘οΈβœ¨


πŸŽ€ INVOCATION πŸŽ€

Absent the -{ program } flag, the first argument is taken to be the name of a file containing a crm114 program, subsequent arguments are merely supplied as :_argN: values. Use single quotes around commandline programs '-{ like this }' to prevent the shell from doing odd things to your command-line programs.

CRM114 can be directly invoked by the shell if the first line of your program file uses the shell standard, as in:

#! /usr/bin/crm114

You can use CRM114 flags on the shell-standard invocation line, and hide them with '--' from the program itself; '--' incidentally prevents the invoking user from changing any CRM114 invocation flags. πŸ”’

Flags should be located after any positional variables on the command line. Flags are visible as :_argN: variables, so you can create your own flags for your own programs (separate CRM114 and user flags with '--'). Two examples on how to do this:

./foo.crm114 bar mugga < baz  -t -w 150000
./foo.crm114 -t -w 1500000 -- bar < baz mugga

One example on how not to do this:

./foo.crm114 -t -w 150000 bar < baz mugga

(That's WRONG! 😭)

You can put a list of user-settable vars on the #!/usr/bin/crm114 invocation line. CRM114 will print these out when a program is invoked directly (e.g. "./myprog.crm114 -h", not "crm114 myprog.crm114 -h") with the -h (for help) flag. (note that this works ONLY on bash on Linux-*BSD's have a different bash interpretation and this doesn't work 😩)

Example:

#!/usr/bin/crm114  -( var1 var2=A var2=B var2=C )

This allows only var1 and var2 be set on the command line. If a variable is not assigned a value, the user can set any value desired. If the variable is equated to a set of values, those are the only values allowed.

Another example:

#!/usr/bin/crm114  -( var1 var2=foo )  --

This allows var1 to be set to any value, var2 may only be set to either foo or not at all, and no other variables may be set nor may invocation flags be changed (because of the trailing "--"). Since "--" also blocks '-h' for help, such programs should provide their own help facility. πŸ™


πŸ’œ VARIABLES πŸ’œ

Variable names and locations start with a : , end with a : , and may contain only characters that have ink (i.e. the [:graph:] class) with few exceptions.

Examples: :here:, :ThErE:, :every-where_0123+45%6789:, :this_is_a_very_very_long_var_name_that_does_not_tell_us_much:. ✨

Builtin variables, the whole squad:

  • :_nl: β€” newline
  • :_ht: β€” horizontal tab
  • :_bs: β€” backspace
  • :_sl: β€” a slash
  • :_sc: β€” a semicolon
  • :_arg0: thru :_argN: β€” command-line args, including all flags
  • :_argc: β€” how many command line arguments there were
  • :_pos0: thru :_posN: β€” positional args ('-' or '--' args deleted)
  • :_posc: β€” how many positional arguments there were
  • :_pos_str: β€” all positional arguments concatented
  • :_env_whatever: β€” environment value 'whatever'
  • :_env_string: β€” all environmental arguments concatenated
  • :_crm_version: β€” the version of the CRM system
  • :_dw: β€” the current data window contents

🌈 VARIABLE EXPANSION 🌈

Variables are expanded by the :*: var-expansion operator, e.g. :*:_nl: expands to a newline character. Uninitialized vars evaluate to their text name (and the colons stay). πŸ‘€

You can also use the standard constant C '\' characters, such as "\n" for newline, as well as excaped hexadecimal and octal characters like \xHH and \oOOO but these are constants, not variables, and cannot be redefined.

Depending on the value of "math mode" (flag -q). you can also use :#:string_or_var: to get the length of a string, and :@:string_or_var: to do basic mathematics and inequality testing, either only in EVALs or for all var-expanded expressions. See "Sequence of Evaluation" below for more details.


🧚 PROGRAM BEHAVIOR 🧚

Default behavior is to read all of standard input till EOF into the default data window (named :_dw:), then execute the program (this is overridden if first executable statement is a WINDOW statement).

Variables don't get their own storage unless you ISOLATE them (see below), instead variables are start/length pairs indexing into the default data window. Thus, ALTERing an unISOLATEd variable changes the value of the default data buffer itself. This is a great power, so use it only for good, and never for evil. 😀


πŸ‘‘ STATEMENTS AND STUFF πŸ‘‘

Statements are separated with a ';' or with a newline.

  • \ β€” '\' is the string-text escape character. You only need to escape the literal representation of closing delimiters inside var-expanded arguments.

You can use the classic C/C++ \-escapes, such as \n, \r, \t, \a, \b, \v, \f, \0, and also \xHH and \oOOO for hex and octal characters, respectively.

A '\' as the last character of a line means the next line is just a continuation of this one.

A \-escape that isn't recognized as something special isn't an error; you may optionally escape any of the delimiters >, ), ], }, ;, /, #, \ and get just that character.

A '\' anywhere else is just a literal backslash, so the regex ([abc])\1 is written just that way; there is no need to double-backslash the \1 (although it will work if you do).

  • # this is a comment
  • # and this too \#

A comment is not a piece of preprocessor sugar -- it is a statement and ends at the newline or at "\#". πŸ’¬

  • insert filename β€” inserts the file verbatim at this line at compile time.
  • ; β€” statement separator - must ALWAYS be escaped as \; unless it's inside delimiters or else it will mark the end of the statement.
  • { and } β€” start and end blocks of statements. Must always be '\' escaped or inside delimiters or these will mark the start/end of a block.
  • noop β€” no-op statement.
  • :label: β€” define a GOTOable label.
  • accept β€” writes the current data window to standard output; execution continues.
  • alius β€” if the last bracket-group succeeded, ALIUS skips to end of {} block (a skip, not a FAIL); if the prior group FAILed, ALIUS does nothing. Thus, ALIUS is both an ELSE clause and a CASE statement. 🎭
  • alter (:var:) /new-val/ β€” destructively change value of var to newval; (:var:) is var to change (var-expanded); /new-val/ is value to change to (var-expanded).
  • classify <flags> (:c1:...|...:cN:) (:stats:) [:in:] /word-pat/ β€” compare the statistics of the current data window buffer with classfiles c1...cN.
  • <flags> β€” if <flags> is set to <nocase>, case gets ignored in word-pat. It does not change case in the hash though β€” nope, the hash stays exactly as-is. If you want case-folding in the hash too, run tr() on :in: yourself, bestie. πŸ’…
  • (:c1: ... β€” the file, or files, you're calling your "success" files. The CLASSIFY succeeds if these files, as a group, match best. And if they don't? The CLASSIFY does a FAIL. πŸ’”
  • | β€” optional separator. And those spaces on each side of the " | " are required, okay, do not skip them.
  • .... :cN:) β€” optional files to the right of " | " get treated as a group that should "fail". If the statement fails, execution skips down to the end of the enclosing {..} block, and that block exits with a FAIL status (peep ALIUS for why that's actually useful).
  • (:stats:) β€” optional var that gets a text formatted matching summary. πŸŽ€
  • [:in:] β€” restrict the statistical measure to just the string inside :in:.
  • /word-pat/ β€” the regex that describes what a parseable word actually is.

  • eval (:result:) /instring/ β€” this one evaluates /instring/ over and over until it stops changing, and then drops that final result in as the value of :result:. EVAL uses smart (but honestly foolable πŸ™ˆ) heuristics to dodge infinite loops β€” stuff like a string that evaluates into a request to evaluate itself all over again. The error rate is about 1 / 2^62, and it will detect chain groups of length 255 or less. One more thing: if the instring uses math evaluation (see the section below on math operations ✨) and that evaluation has an inequality test (>, < or =) and the inequality fails, then the EVAL will FAIL to the end of block. And if the evaluation hits a numeric fault (e.g. divide-by-zero 😭), the EVAL does a TRAPpable FAULT.
  • exit /:retval:/ β€” ends program execution, periodt. If a retval is supplied, the return value is converted to an integer and returned as the exit code of the crm114 program. If no retval is supplied, the return value is 0.
  • fail β€” skips down to the end of the current { } block and causes that block to exit with a FAIL status (again, see ALIUS for why this is useful).
  • fault /faultstr/ β€” forces a FAULT with the given string as the reason. The fault string is val-expanded. πŸ’€
  • goto /:label:/ β€” unconditional branch. And yes, you can use a variable as the goal, e.g. /:*:there:/. πŸ¦‹
  • hash (:result:) /input/ β€” computes a fast 32-bit hash of /input/ and ALTERs :result: to the hexadecimal hash value. Big heads-up though: HASH is not warranted to be constant across major releases of CRM114, and it is not cryptographically secure. Protect your peace accordingly, bestie.
    • (:result:) β€” the value that gets the result.
    • /input/ β€” the string to be hashed. It can contain expanded :*:vars:, and it defaults to the data window :_dw:.
  • intersect (:out:) [:var1: :var2: ...] β€” makes :out: contain the part of the data window that's the intersection of :var1 :var2: .... Any ISOLATEd vars get ignored. Important: this only resets the value of the captured variable, and does NOT alter any text in the data window. 🌸
  • isolate (:var:) /initial-value/ β€” puts :var: into a data area outside of the data buffer. After that, changes to this var don't change the data buffer (though they may change the value of any var that gets set later inside of this var). And if the var was already ISOLATED, this is a noop. 🫢
    • (:var:) β€” name of the ISOLATEd var (var-expanded).
    • /initial-value/ β€” optional initial value for :var: (var-expanded). If no value is supplied, the previous value is retained/copied.
  • input <flags> (:result:) [:filename:] β€” reads in the content of filename. If there's no filename, then it reads stdin. πŸ“
    • <byline> β€” read one line only.
    • (:result:) β€” the var that gets the input value.
    • [:filename:] β€” the file to read.
  • learn <flags> (:class:) [:in:] /word-pat/ β€” learns the statistics of the :in: var (or the input window, if there's no var) as an example of class :class:. πŸ‘‘
    • <flags> β€” can be any of <nocase>, <refute> and <microgroom>. <nocase>: ignore case in matching word-pat (it does not ignore case in the hash β€” use tr() to do that on :in: if you want it). <refute>: this is an anti-example of this class β€” unlearn it! <microgroom>: enable the microgroomer, so less-important information gets purged automatically whenever the statistics file gets too crowded. 🧹
    • (:class:) β€” name of the file holding hashed results; the nominal file extension is .css.
    • [:in:] β€” captured var containing the text to be learned (if omitted, the full contents of the data window is used).
    • /word-pat/ β€” regex that defines a "word". Things that aren't "words" are ignored.
  • liaf β€” skips UP to the START of the current {} block. (LIAF is FAIL spelled backwards, which is honestly so iconic of it. πŸ™ˆ)
  • match <flags> (:var1: ...) [:in:] /regex/ β€” attempts to match the given regex. If the match succeds, variables are bound; if the match fails, the program skips to the closing } of this block. 😀
    • <flags> β€” flags can be any of:
      • <ab β€” statement succeeds if match not present
      • <no β€” ignore case when matching
      • <frstartr β€” match at start of the [:in:] var
      • <frstartr β€” match at start of previous successful match on the [:in:] var
      • <frstartt β€” match at one character past the start of the previous successful match on the [:in:] var
      • <frstart> β€” match at one character past the end of prev. match on this [:in:] var
      • <ne β€” require match to end after end of prev. match on this [:in:] var
      • <ba β€” searchs backward in the [:in:] variable from the last successful match.
      • <nodon'tl β€” allow this match to span lines
    • (:var1: ...) β€” optional variables to bind to the regex result and the ( ) subregexes.
    • [:in:] β€” search only in the variable specified; if omitted, :_dw: (the full input data window) is used.
    • /regex/ β€” POSIX regex (with \ escapes as needed).
    • And if you build CRM114 to use the GNU regex library for MATCHing, be warned: GNU REGEX has numerous issues. See the KNOWN_BUGS file for a detailed listing. 🫣
  • output <flags> [filename] /output-text/ β€” outputs an arbitrary string with captured values expanded. πŸ’–
    • <flags> β€” <append>: append to the file (otherwise, it overwrites).
    • [filename] β€” filename to send output to (var-expanded); the default output is to stdout.
    • /output-text/ β€” the string to output (var-expanded).
  • syscall <flags> (:in:) (:out:) (:status:) /command/ β€” execute a shell command. 🐚
    • <flags> β€” can be any of <keep> and <async>. <keep>: keep this process around; if it's kept, then a syscall with the same :keep: var will continue feeding to and reading from the kept proc. <async>: don't wait for the process to send an EOF; just grab what's available in the process's output pipe and proceed (limit per syscall is 256 Kbytes).
    • (:in:) β€” var-expanded string to feed to the command as input (can be null if you don't want to send the process something). You must specify this if you want to specify an :out: variable.
    • (:out:) β€” var-expanded varname to place results into (must pre-exist, and can be null if you don't want to read the process's output yet, or at all). Limit per syscall is 256 Kbytes. You must specify this if you want to use the :status: variable.
    • (:status:) β€” if you want to keep a minion proc around, or catch the exit status of the process, specify a var here. The minion process's PID and pipes get stored here. The program can access the proc again with another syscall by using this var again. When the process exits, its exit code will be stored here.
  • trap (:reason:) /trap_regex/ β€” traps faults from both FAULT statements and program errors occurring anywhere in the preceding bracket-block. If no fault exists, TRAP does a SKIP to end of block. If there is a fault and the fault reason string matches the trap_regex, the fault is trapped and execution continues with the line after the TRAP β€” otherwise the fault is passed up to the next surrounding trapped bracket block. πŸͺ€
    • (:reason:) β€” the fault message that caused this FAULT. If it was a user fault, this is the text the user supplied in the FAULT statement.
    • /trap_regex/ β€” the regex that determines what kind of faults this TRAP will accept. Put a wildcard here (e.g. /.*/) and ALL faults will be trapped here.
  • union (:out:) [:var1: :var2: ...] β€” makes :out: contain the union of the data window segments that contains var1, var2... plus any intervening text as well. Any ISOLATEd var is ignored. This is non-surgical, and it does not alter the data window. 🌈
  • window <flags> (:w-var:) (:s-var:) /cut-regex/ /add-regex/ β€” window slider ✨. This deletes to and including the cut-regex from :var: (default: use the data window), then reads adds from std. input till add-regex (inclusive).
    • <flags> β€” flags can be any of
  • <nocase> β€” bestie, it's literally just "ignore case when matching cut-and-add- regexes". Vibe check passed, uppercase does not matter here. πŸ”€
  • <bychar> β€” peep the input for the add-regex every single character. one. char. at. a. time. πŸ’…
  • <byline> β€” same energy but every line instead. so chill.
  • <byeof> β€” don't check for the add-regex until EOF shows up. (the extra characters are kept around for later, they're not ghosted, they're just waiting their turn 🫢)
  • <eofends> β€” read lots of input; the input is up to the regex match OR the contents till EOF. either/or, no cap.
  • (:w-var:) β€” which var to window, obviously.
  • (:s-var:) β€” which var to use for the source (defaults to stdin, and if you use a source var you must specify the windowed var, that's not optional bestie).
  • /cut-regex/ β€” the var-expanded cut pattern.
  • /add-regex/ β€” the var-expanded add pattern, and if it's absent it reads till EOF. classic.

If both cut-regex and add-regex are omitted, and this window statement is the first executable statement in the program, then CRM114 does not wait to read anything from standard input before starting program execution. iconic behavior, honestly. ⚑


🌈 A QUICK REGEX INTRO 🌈

A regex is a pattern match. Go do a man 7 regex for the details, iykyk. πŸ“–

Matches are, by default, "first starting point that matches, then longest match possible that can fit". that's the whole philosophy right there.

  • a through z β€” all match themselves πŸ’–
  • A through Z β€” all match themselves πŸ’–
  • 0 through 9 β€” all match themselves πŸ’–
  • most punctuation β€” matches itself, but check below! don't come for me, there's a twist.
  • * β€” repeat preceding 0 or more times
  • + β€” repeat preceding 1 or more times
  • ? β€” repeat preceding 0 or 1 time
  • *?, +?, ?? β€” repeat preceding, but shortest match that fits, given the already-selected start point of the regex. (only supported by TRE regex, not GNU regex β€” know your engine, bestie 😭)
  • [abcde] β€” any one of the letters a, b, c, d, or e ⭐
  • [a-q] β€” the letters a through q (just one of them)
  • {n,m} β€” repetition count: match the preceding at least n and no more than m times (POSIX restricts this to a maximum of 255 repeats)
  • [[:<:]] β€” matches at the start of a word (GNU regex only)
  • [[:>:]] β€” matches the end of a word (GNU regex only)
  • ^ β€” as first char of a match, matches the start of a line (ONLY in <nomultiline> matches. yes only, read it again 🫠)
  • $ β€” as last char of a match, matches at the end of a line (ONLY in <nomultiline> matches)
  • . β€” (a period) matches any single character (except start-of-line or end of line "virtual characters", but it does match a newline). yes it's weird, we love it anyway.
  • a|b β€” match a or b
  • (match) β€” the () go away, and the string that matched inside is available for capturing. Use \\( and \\) to match actual parenthesis (the first '' tells "show the second '' to the regex engine, the second '' forces a literalization onto the parenthesis character. πŸ’€)
  • \n β€” matches the N'th parenthesized subexpression. Remember to backslash-escape the backslash (e.g. write this as \\1) This is only if you're using TRE, not GNU regex. ⚠️

The following are other POSIX expressions, which mostly do what you'd guess they'd do from their names. and honestly? they do. slay.

  • [[:alnum:]]
  • [[:alpha:]]
  • [[:blank:]]
  • [[:cntrl:]]
  • [[:digit:]]
  • [[:lower:]]
  • [[:upper:]]
  • [[:graph:]]
  • [[:print:]]
  • [[:punct:]]
  • [[:space:]]
  • [[:xdigit:]]

[[:graph:]] matches any character that puts ink on paper or lights a pixel. ✨ [[:print:]] matches any character that moves the "print head" or cursor. yes we're being poetic about characters, it's fine, it's valid.


🧠 NOTES ON SEQUENCE OF EVALUTATION 🧠

By default, CRM114 supports string length and mathematical evaluation only in an EVAL statement, although it can be set to allow these in any place where a var-expanded variable is allowed (see the -q flag). The default value ( zero ) allows stringlength and math evaluation only in EVAL statements, and uses non-precedence (that is, strict left-to-right unless parenthesis are used) algebraic notation. -q 1 uses RPN instead of algebraic, again allowing stringlength and math evaluation only in EVAL expressions. Modes 2 and 3 allow stringlength and math evaluation in any var-expanded expression, with non-precedence algebraic notation and RPN notation respectively. Evaluation is always left-to-right; there is no precedence of operators beyond the sequential passes noted below. and now, the four passes, in order, no skipping, we do not skip here πŸ‘‘

  1. `-constants like \n, \o377 and \x3F are substituted
  2. :*:var: variables are substituted (note the difference between a constant like '\n' and a variable like ":*:_nl:" here β€” constants are substituted first, then variables are substituted.)
  3. :#:var: string-length operations are performed
  4. :@:expression: mathematical expressions are performed; syntax is either RPN or non-precedenced (parens required) algebraic notation. Embedded non-evaluated strings in a mathematical expression is currently a no-no. πŸ™…
Allowed operators are: + - * / % > < = only. that's the whole roster. no extras, no guests.

Only >, <, and = set logical results; they also evaluate to 1 and 0 for continued chain operations β€” e.g.

((:*:a: > 3) + (:*:b: > 5) + (:*:c: > 9) > 2)

is true IFF any of the following is true

  • a > 3 and b > 5
  • a > 3 and c > 9
  • b > 5 and c > 9

three ways to win, pick your fighter πŸ’œ


πŸ¦‹ NOTES ON APPROXIMATE REGEX MATCHING πŸ¦‹

Only the TRE engine supports approximate matching. The GNU engine does not support approximate matching. periodt. ❌

Approximate matching is specified similarly to a "repetition count" in a regular regex, using brackets. This approximation applies to the previous parenthesized expression (again, just like repetion counts). You can specify maximum total changes, and how many inserts, deletes, and substitutions you wish to allow. The minimum-error match is found and reported, if it exists within the bounds you state. so forgiving. so generous. main character energy fr fr.

The basic syntax is:

(text-to-match){~[maxerrs] [#maxsubsts] [+maxinserts] [-maxdeletes]}

Note that the '~' (with an optional maxerr count) is required (that's how we know it's an approximate regex rather than just a rep-count); if you don't specify a max error count, you will get the best match, if you do, the match will have at most that many errors. πŸŽ€

Remember that you specify the changes to the text in the pattern necessary to make it match the text in the string being searched. yes, that direction. don't get it twisted.

You cannot use approximate regexes and backrefs (like \1) in the same regex. This is a limitation of in TRE at this point. 😭 not me apologizing on TRE's behalf.

You can also use an inequality in addition to the basic syntax above:

(text-to-match){~[maxerrs] [basic-syntax] [nI + mD + oS < K] }

where n, m, and o are the costs per insertion, deletion, and substitution respectively, 'I', 'D', and 'S' are indicators to tell which cost goes with which kind of error, and K is the total cost of the errors; the cost of the errors is always strictly less than K. Here are some examples. πŸ‘‡

  • (foobar) β€” exactly matches "foobar" 🎯
  • (foobar){~} β€” finds the closest match to "foobar", with the minimum number of inserts, deletes, and substitutions. Always succeeds. always!! πŸ’–
  • (foobar){~3} β€” finds the closest match to "foobar", with no more than 3 inserts, deletes, or substitutions
  • (foobar){~2 +2 -1 #1) β€” find the closest match to "foobar", with at most two errors total, and at most two inserts, one delete, and one substitution.
  • (foobar){~4 #1 1i + 2d < 5 } β€” find the closest match to "foobar", with at most four errors total, at most one substitution, and with the number of insertions plus 2x the number of deletions less than 5.
  • (foo){~1}(bar){~1) β€” find the closest match to "foobar", with at most one error in the "foo" and one error in the "bar". splitting the error budget, we love a fair division πŸ“

πŸ‘‘ OVERALL LANGUAGE NOTES πŸ‘‘

Here's how to remember what goes where in the CRM114 language. study guide era.

Unlike most computer languages, CRM114 uses inflection (or declension) rather than position to describe what role each part of a statement plays. The declensions are marked by the delimiters β€” the /, ( and ), < and >, and [ and ]. grammar queen πŸ‘‘

By and large, you can mix up the arguments to each kind of statement without changing their meaning. Only the ACTION needs to be first. Other parts of the statement can occur in any order, save that multiple (paren_args) and /pattern_args/ must stay in their nominal order but can go anywhere in the statement. They do not need to be consecutive. flexible but not chaotic, the best combo ✨

The parts of a CRM114 statement are:

  • ACTION β€” the verb. This is at the start of the statement. it goes first, always.
  • /pattern/ β€” the overall pattern the verb should use, analogous to the "subject" of the statement.
  • <flags> β€” modifies how the ACTION does the work. You'd call these "adverbs" in human languages.
  • (vars) β€” what variables to use as adjuncts in the action (what would be called the "direct objects"). These can get changed when the action happens. watch out, they move πŸ‘€
  • [limited-to] β€” where the action is allowed to take place (think of it as the "indirect object"). These are not directly changed by the action.

🌸 SEE ALSO 🌸

cssmerge(1), cssdiff(1), cssutil(1)

The CRM114 homepage is at http://crm114.sf.net/ . go say hi 🫢


πŸ’œ VERSION πŸ’œ

This manpage: $Id: crm114.azm,v 1.12 2004/08/19 11:10:49 vanbaal Exp $

This manpage describes the crm114 utility as it has been described by QUICKREF.txt, shipped with crm114-20040212-BlameJetlag.src.tar.gz. The DESCRIPTION section is copy-and-pasted from INTRO.txt as distributed with the same source tarball.

Converted from plain ascii to zoem by Joost van Baal.


Copyright (C) 2001, 2002, 2003, 2004 William S. Yerazunis

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. (yes bestie, the all-caps warranty disclaimer means business, that's the legal vibe πŸ’€)

You should have received a copy of the GNU General Public License along with this program (see COPYING); if not, check with http://www.gnu.org/copyleft/gpl.html or write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.


🌟 AUTHOR 🌟

William S. Yerazunis. Manpage typesetting by Joost van Baal and Shalendra Chhabra


and that's the whole page bestie!! πŸŽ€ this was crm114 20040816.BlameClockworkOran19-Augo2004 for crm114(1), dated 19-Aug-2004 β€” legendary version name, honestly, whoever named that build ate and left no crumbs. go forth and filter your mail, ily, mwah πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from
  • ubuntu stonking: crm114 20100106-12
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms