SEARCH(nged)

okay bestie, this is the SEARCH(nged) page from BRL-CAD User Commands — it’s basically find(1) energy but for objects in your MGED database instead of files on disk. 💅

💖 NAME 💖

search — find and list objects in a BRL-CAD database.

✨ SYNOPSIS ✨

search [-a] [-v] [-Q] [-h] [path] [expressions...]

🦋 DESCRIPTION 🦋

search works in a fashion similar to Unix-style find commands (internally it is based on OpenBSD's and NetBSD's find code) but searches objects in the current open database in MGED rather than files in a file system. One or more search paths are specified for searching, and a search plan specifies filters through which objects in the search paths are tested. The names of objects satisfying all of the filters are returned as the command output. 🫶

Search Inputs are specified using PATHS and matching of objects is done according to a search plan built using boolean expressions constructed using the PRIMITIVES and OPERATORS described below. Note that OPTIONS are not used to form search plans — unlike the search plan they are specified before the paths and are used to control settings that apply globally to search's behavior and reporting during the execution of the search. no cap, options are their own little vibe check.

The results of the search command will be sorted according to David Koelle's "alphanum" algorithm, which is basically a human-intuitive ordering for strings with letters and numbers. For example, a result returning d1.r, d10.r and d2.r will be sorted as:

d1.r
d2.r
d10.r

instead of the default ASCII character ordering, which would look like:

d1.r
d10.r
d2.r

💅 OPTIONS 💅

• -h — Print help and exit.
• -a — Include hidden objects when assembling implicit, top-level, or flat input lists and when walking search hierarchies.
• -Q — Exit quietly without printing error messages if the search plan contains errors. Primarily used in situations where programs automatically generate search invocations.
• -v[v..] — Prints extra (verbose) information in results. Can be stacked up to 3 times for increasingly verbose printing. (See Example 22 for in-depth usage)

🌸 PATHS: 🌸

By default, only the "top level" objects in any search are used as starting points in the search. The default mode if no path is explicitly specified returns a list of all objects found matching the criteria using the top level objects as inputs. Specifying paths is done as follows:

Table 1. Path Specifiers

• / — Search using top level objects in database as starting points, return list of matching full paths.
• . — Search using top level objects in database as starting points, return list of all matching objects (default).
• | — Iterate over all objects in the database without doing a tree walk, return list of all matching objects.
• |/ — flat version of /: uses every object in the database as a starting point for a full tree walk, then returns matching full paths.
• |. — flat version of .: uses every object in the database as a starting point for a full tree walk, then returns all matching objects.
• objname — Use object objname as the starting point, return list of matching full paths.
• /objname — Use object objname as the starting point, return list of all matching objects.
• |objname — Use every object below objname as starting points, return list of all matching objects.

One search command may use multiple paths, each of which can specify its own mode — such a "mixed mode" search will return a list of full paths and objects in the order paths were supplied to search. 🎀

The "flat" searches that are specified by using | as a modifier to other paths will use every object in the database as starting points for full tree walks and consequently will be significantly more expensive for complex tree hierarchies. The "truly flat" iterative search triggered by the the stand-alone | path specifier will be faster, but because it does not walk the tree hierarchy depth-related options (-above, -below, -depth, etc.) will not function. iykyk, flat is fast until depth options ghost you.

🔥 PRIMITIVES: 🔥

🌟 -attr attrib[>/</=val] 🌟

Returns TRUE if the object has attribute attrib. If a specific value is also supplied for the attribute with an equal condition, TRUE is returned if the object both has the attribute and the attribute is set to value val. In the case of >, <, >=, and <= there are two possibilities — if val is numerical a numerical comparison is performed, otherwise a string comparison is performed. Both attrib and val are treated as patterns under shell pattern matching rules when a string comparison is performed, but in numerical mode only the attribute name is pattern matched.

🌟 -bool u/+/− 🌟

True if the object in question is being combined into the local hierarchy with the specified boolean operation. Recognized types are Union (u), Intersection (+), and Subtraction (-).

Note that by convention, top level objects are implicitly "unioned" into the database. To see only objects that have been unioned into a comb tree without returning the top level comb object as well, use the -mindepth option to filter for returns deeper in the tree.

🌟 -depth [>/</=]depth 🌟

True if the depth of the object in the tree is within the range specified.

🌟 -exec expression arg1 arg2 ... ";" 🌟

Pass expression and its arguments to the host application's search execution handler. The filter is true if the handler reports success and false if it reports an error; a textual command result is not interpreted as a boolean. The commands available to -exec depend on the host application. Any pair of curly braces ({}) in an argument is replaced by the name or full path of the object. The semicolon terminates the argument list and must not be omitted. Remember to quote the parameters properly. The semicolon must stand on its own and must be quoted. 😭

bestie, do not forget that semicolon. it is not decorative. it is the whole assignment. 💀

When using multiple -exec filters, keep in mind that filters are evaluated lazily, so if you have two -execs and the first one returns false for one node, the second one will not run at all.

🌟 -iname pattern 🌟

Like name except the match is case insensitive.

🌟 -iregex pattern 🌟

Like regex except the match is case insensitive.

• -matrix IDN|{#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#} — true when the object in question is being combined into the local hierarchy with the specified matrix ✨. This one is so good when you pair it with the ! operator for finding objects in a hierarchy with matrices over them — iykyk. And IDN is a shorthand that lets you specify an identity matrix more succinctly, which, thank you, because typing all those numbers is a ✨choice✨.
• -maxdepth n — true if the depth of the object in the tree is less than or equal to n.
• -mindepth n — true if the depth of the object in the tree is greater than or equal to n.
• -name pattern — true if the object name matches pattern — and bestie, that's the name only, not the full path, just the name 💅. The evaluation is done according to shell pattern matching rules.
• -nnodes n — true if the object is a combination and has n nodes. This one also supports supplying <, >, <=, and >= in front of the number, so you can get true for objects with node counts less than, greater than, less than or equal to, and greater than or equal to n. Slay, comparison operators.
• -param param[>/</=val] — returns TRUE if the object has parameter param. And here's the tea: unlike -attr, which looks only at general attributes stored as metadata on objects, the -param filters based only on the internal geometric object's characteristics 🫶. If a specific value is also supplied for the parameter with an equal condition, TRUE is returned if the object both has the parameter and the parameter is set to value val. In the case of >, <, >=, and <= there are two possibilities — if val is numerical a numerical comparison is performed, otherwise a string comparison is performed. Both attrib and val are treated as patterns under shell pattern matching rules when a string comparison is performed, but in numerical mode only the parameter name is pattern matched. No cap.

The following table outlines what parameters are visible to the -param option 👑. Because BRL-CAD uses the same internal containers for some types, some parameters will be present even when they do not make sense for the specific subtype — examples include using arb8's container for arb4 and tgc for rcc 🙈. Note: there are also a number of primitives whose parameters are not exposed in a way that that -param can access them: arbn, ars, brep, bspline, dsp, metaball, nmg, pipe, pnts, and poly. So if your fave is on that list, that's literally why the vibe check failed.

🎀 Table 2. Primitive Parameters 🎀

• arb8 (arb4, arb5, arb6, arb7) — V1, V2, V3, V4, V5, V6, V7, V8
• bot — mode[surf,volume,plate,plate_nocos], orient[no,lh,rh], V, F, T
• cline — V, H, R, T
• ebm — F, W, N, H, M
• ehy — V, H, A, r_1, r_2, c
• ell (sph) — V, A, B, C
• epa — V, H, A, r_1, r_2
• eto — V, N, C, r, r_d
• extrude — V, H, A, B, S, K
• grip — V, N, L
• half — N, d
• hf — cfile, dfile, fmt, w, n, shorts, file2mm, v, x, y, xlen, ylen, zscale
• hyp — V, H, A, b, bnr
• part — V, H, r_v, r_h
• revolve — V, axis, R, ang, sk_name
• rhc — V, H, B, r, c
• rpc — V, H, B, r
• sketch — V, A, B, VL, SL
• submodel — file, treetop, meth
• tgc (rcc, rec, tec, trc) — V, H, A, B, C, D
• tor — V, H, r_a, r_h
• vol — file, w, n, d, lo, hi, size, mat
• -path pattern — true if the object path matches pattern. The evaluation is done according to shell pattern matching rules.
• -print — evaluates to TRUE 💖 — used to print out the path and name of the object.
• -regex pattern — true if the object's path matches pattern. The matching here is done with Regular Expression matching, so go off with your regex self 💅
• -size [>/</=]size — true if the object's size lands inside the range you specified. Big note though bestie: for combs, extrudes, and other composite objects, this filter only looks at the object definition itself, not its related elements. So don't come for it expecting it to count the whole squad 🙈
• -stdattr — returns TRUE if an object has ONLY standard attributes attached to it. In BRL-CAD, the standard attributes are literally these:
  • GIFTmater — value type #
  • inherit — value type 0 or 1
  • material_id — value type #
  • oshader — value type shader string
  • region_id — value type #
  • rgb — value type #/#/#
• -type pattern — returns TRUE if the object's type matches pattern. This one uses shell pattern matching for the evaluation, so it's giving glob energy ✨ Types it recognizes include:
  • arb4, arb5, arb6, arb7, arb8, arbn
  • annot, ars, binunif, bot, brep, bspline
  • cline, constrnt, datum, dsp, ebm, ehy
  • ell, epa, eto, extrude, grip, half
  • hf, hrt, hyp, joint, metaball, nmg
  • part, pipe, pnts, poly, rec, rhc
  • rpc, script, sketch, sph, submodel, superell
  • tgc, tor, vol

And for the combinations, these are the types and the abbreviations it recognizes:

• combination — c, comb, combination
• region — r, reg, region

Also, as a little convenience treat 🎀 the -type option will also recognize the pattern shape, which matches any object that is not a combination, region, annotation, constraint, grip or joint. Not me giving you a catch-all, but she did that 💅

And okay so if you're trying to identify shapes that are defined as implicit solids using the "plate mode" methodology — the pattern plate is your girl. It matches any object whose internal definition indicates it's of that type. Currently that's possible with bot and brep objects. 🔥

The pattern volume is basically the mirror of plate: it reports objects that clearly define a non-implicit solid volume. But heads up, its determination is local — like, combs aren't matched because a comb may be made up of non-volumetric objects. In particular, plate mode objects won't match because their volume is implicit, and (for example) surface mode BoTs won't match because they don't define a volume. It's giving "read the room, the room is the local definition" 😭

---

💥 OPERATORS 💥

• ( expression ) — evaluates to true when the expression inside the parentheses is true. It’s the “bestie, please respect my order of operations” move 💅.
• -below[>/</=val] expression — true if an ancestor of the current path satisfies expression. The current object itself is not tested by expression. For example, -below -name start_comb.c is true for both /component/region.r/start_comb.c/prim1.s and any deeper descendants of start_comb.c, but it’s false for start_comb.c itself. No cap.

An optional comparison constrains the number of hierarchy edges between the current object and the ancestor being tested. The immediate parent is at relative depth 1, its parent is at relative depth 2, and so on. So -below=1 -type region selects objects whose immediate parent is a region, while -below>1 -type region requires a matching region at least two levels above the current object. The unqualified form tests all ancestors. Slay.

Nested forms such as -below -below -name X are valid. They test whether the current object has an ancestor which is itself below an ancestor matching X. See Hierarchy Operator Performance before using constrained or action-bearing forms on large hierarchies. Fr fr, check the performance tea first ☕.

• expression -and expression (a.k.a. -a) — the and operator operates like the logical AND operator: TRUE only if both expressions are true. AND is the default operator assumed if two expressions are present with no operator explicitly defined. It’s giving “if both of you are coming, then it’s a party” 🎀.
• -above[>/</=val] expression — true if a descendant of the current path satisfies expression. The current object itself is not tested by expression. For example, -above -name prim1.s is true for /component, /component/region.r, and /component/region.r/start_comb.c when prim1.s is below them, but it’s false for prim1.s itself.

An optional comparison constrains the number of hierarchy edges between the current object and the descendant being tested. An immediate child is at relative depth 1. Thus, -above=1 -name prim1.s matches only direct parents of prim1.s; the unqualified form tests descendants at every depth.

Using -above as the expression within another -above (for example, -above -above -name X) is valid, but may be dramatically slower than an ordinary -above. See Hierarchy Operator Performance. Basically: valid, but it can be a lil dramatic 😭.

• -not expression (a.k.a. !) — the logical NOT operator. Returns the opposite of the evaluation result of expression. It’s the “flip the vibe check” button.
• expression -or expression (a.k.a. -o) — the logical OR operator. True if either expression is true. One of them showing up is enough, iconic behavior ✨.

🔥 Hierarchy Operator Performance 🔥

Ordinary, unconstrained, side-effect-free -above and -below expressions use cached propagation and are intended for large searches. Pure boolean composition with -and, -or, parentheses, or ! does not by itself disable these hierarchy caches. The following cases automatically require exhaustive evaluation instead:

• Any -exec anywhere in a plan containing -above or -below disables all hierarchy-result caching for that plan. This is necessary because the callback may change the database, and later filters must observe those changes even when -exec is in a different -and or -or branch. Like, the database said “I’m different now,” and the filters have to respect that 💅.
• A -below with a relative-depth comparison, or whose expression contains an explicit action such as -exec or -print, may inspect the ancestor chain separately for every candidate. Its cost is proportional to the number of paths times their depth and can become quadratic on a deep chain. Unconstrained nested -below expressions remain cached when they contain no actions; in the unusual case of more than 64 cached -below operators, additional operators use exhaustive evaluation. Sixty-four is the vibes limit, apparently 👑.
• A depth-constrained -above, an -above whose expression contains an explicit action, or an -above directly nested inside another -above may compare candidates against the collected path set repeatedly. These forms can be quadratic in the number of paths. Oof.
• Nesting hierarchy operators that require these exhaustive forms can compound the cost beyond quadratic. It’s giving “this could get real expensive real fast” 💀.

The implicit final -print added by search does not disable caching. Only an explicit -print inside the hierarchy expression does so. Important distinction, bestie 🫶.

Traversal pruning by -maxdepth is also conservative. An -or permits pruning only when every branch has a -maxdepth bound; for example, -maxdepth 2 -or -name *.s cannot prune, while -maxdepth 2 -or -maxdepth 4 can prune below depth 4. A -maxdepth under !, -above, or -below does not bound the outer traversal. Actions are evaluated from left to right, so -exec ... ";" -and -maxdepth 2 cannot prune before running the action, whereas placing -maxdepth 2 first permits pruning and prevents the later action from running below that depth.

⚠️ Warning — on large, deep, or heavily shared models, the number of full paths can be much larger than the number of database objects. The exhaustive forms above can therefore take an untenably long time and may appear to have hung. Not the cute kind of suspense 😭.

When possible, start from the narrowest applicable path, put inexpensive selective filters such as -name, -type, or -depth before a costly hierarchy operator, and avoid relative-depth constraints or nested hierarchy operators when an equivalent simpler plan is available. Test unavoidable exhaustive plans on a representative subtree before applying them to the complete database. Be smart, be safe, protect your runtime 🌸.

💬 A NOTE ON EXPRESSIONS 💬

All primaries and operands must be expressed as separate arguments to search. In practice, this means that there must be a space between each element in a search expression. E.g. !(-name [a-z] -or -name [0-9]) must be written as:

! ( -name [a-z] -or -name [0-9] )

While this may seem like a rather verbose way of writing the expression, it greatly simplifies the parsing of the expression and is standard for virtually all find type commands. Because [a-z] and [0-9] are atomic arguments as far as search is concerned, they should NOT be expanded in a similar fashion. The parser said “give me spaces,” and honestly? We respect it 👑.

🔮 A NOTE ON SPECIAL CHARACTERS 🔮

Depending upon your environment, special characters such as wildcards or brackets may require an escape character (\). Double quotes can also be used to surround the expression negating the need for multiple escape characters. The following three examples show a search for names containing the string "tire" using two wildcards.

search -name *tire*

search -name \*tire\*

search -name "tire"

If an escape character is required but not used, an "unknown option passed to find_create" error will be displayed. So if you see that, it’s not a mystery, it’s the shell/parser saying “bestie, you forgot the escape” 🙈.

💖 Example 1 — Shell Globbing Based Pattern Match of Object Name 💖

search -name *.s

Finds literally every object in the database whose name ends in ".s". Slay.

🌸 Example 2 — Full Path Instance Reporting of Search Results 🌸

search / -name *.s

Finds every instance of objects in the database with names ending in ".s". Yes bestie, there's a difference — we'll get to it.

🦋 Example 3 — Name Pattern Matching at Depth >= 3 🦋

search / -name *.s -mindepth 3

Finds all the instances of objects whose names end in ".s" that are 3 or more levels deep in their tree. Deep cuts only.

🎀 Example 4 — Finding all Objects in a Subtree 🎀

search group1 -name *.r

Finds all objects within group1 in the database that have names ending in ".r". Heads up though: this returns a list of objects, not the full path info associated with each instance of the matched objects. Just the objects themselves, no lore.

✨ Example 5 — Finding all Instances of Objects in a Subtree ✨

search /group1 -name *.r

Finds all instances of objects within group1 whose names end in ".r". And unlike the previous example, this one does hand you the full path information associated with each instance of the objects matched. That leading / is doing so much work, iykyk.

🧚 Example 6 — Finding all Instances of a Sub-Path 🧚

search / -path \*r245

Finds all paths that end with the object r245. Note bestie: all paths generated by objects below r245 will not match this pattern. If you want to find all paths with r245 in them, use this pattern instead:

search / -path \*r245\*

And if you need to match an object path that's potentially ambiguous (say, r1 when there are lots of regions matching the r1* globbing rule), add the trailing slash to the expression:

search / -path \*r1\/\*

🔥 Example 7 — Searching by Type 🔥

search . -type eto

Finds all objects in the database that are elliptical tori. And note that a path of "." produces the same search behavior as the default behavior for an unspecified path. Same vibe, different spelling.

🫶 Example 8 — Finding all Instances of Nested Regions 🫶

search / -type region -below -type region

Finds all instances of objects of type region that are nested within another region. So it's searching for regions being used within the subtrees of other regions — which is, and I cannot stress this enough, considered bad practice in BRL-CAD. Not the moment.

👑 Example 9 — Finding all Assemblies 👑

search / -type comb ! -below -type region ! -type region

Finds all instances of objects of type combination that are not below regions and are not themselves regions. These are regarded as "assemblies" in BRL-CAD. Main character objects, honestly.

💅 Example 10 — Finding all Combinations below Regions 💅

search / -type comb -below -type region ! -type region

Finds all instances of combinations that are not regions and are located within a region (below a region in the hierarchy). Combs living inside regions, we see you.

🍓 Example 11 — Finding all Empty Combinations 🍓

search -nnodes 0

Finds all combinations containing zero nodes. Empty combs, no thoughts, head empty.

🌈 Example 12 — Finding all Combinations With 10 or More Nodes 🌈

search -nnodes >=10

Finds all combinations with 10 or more nodes. Busy combs, thriving.

⭐ Example 13 — Finding all Intersected Objects ⭐

search -bool +

Finds all objects that are combined into one or more trees using the Intersect boolean operation somewhere in the .g file. Important caveat: this approach only identifies which objects are intersected somewhere in the tree — it does not tell you where specifically they're intersected.

🌸 Example 14 — Finding all Instances of Object Intersection 🌸

search / -bool +

Finds all boolean operations that use the Intersect boolean operation and reports the full paths to those objects. So this reports all the individual cases where an object has been combined into a hierarchy by intersection, not just which objects have been included with the intersection operator. Receipts AND locations 💖

🦋 Example 15 — Finding all Unions Within a Comb's Tree 🦋

search /all.g -mindepth 1 -bool u

Finds all unions within the all.g tree hierarchy, excluding all.g itself. -mindepth 1 said "not you, queen."

💜 Example 16 — Finding all Non-Subtracted Regions below Regions 💜

search / -type region -below -type region ! -bool -

A more nuanced variation on finding nested regions, which adds a check to make sure the regions aren't being subtracted. So real talk — while this isn't ideal, using a subtraction does avoid the modeling error of two volumes claiming the same three dimensional space, and it's arguably acceptable. The -below command is the one that finds nested region instances that are considered errors.

✨ Example 17 — Finding all Non-Identity Matrix Instances ✨

search / ! -matrix IDN

Reports all comb instances included in their parent comb with a non-identity positioning matrix. We love a transformed king.

🎀 Example 18 — Finding all Regions with RGB color 180 180 180 🎀

search -type region ( -attr color=180/180/180 -or -attr
rgb=180/180/180 )

Prints all regions with their color attribute set to 180/180/180. Some files may use rgb instead of color, so to be comprehensive an -or option is used to check both possibilities. Covering all bases, periodt.

🧚 Example 19 — Find All Combs Containing At Least One of Two Objects (dbfind) 🧚

search |. ( -depth 0 -above=1 -name obj1 ) -or ( -depth 0 -above=1
-name obj2 )

Prints all combs immediately above either obj1 or obj2. This more or less mimics the results of the dbfind command — although it'll be somewhat slower (noticeably so on large databases). Worth it though.

🔥 Example 20 — Finding all regions containing an intersection of obj2 🔥

search |/ -maxdepth 0 -type region -above ( -name obj2 -bool + )

Prints all regions immediately above obj2 where obj2 is included using an intersection operation.

👑 Example 21 — Finding all Plate-Mode BoT Objects 👑

search -type bot -param mode=plate

Prints all BoT primitives using "plate" mode, instead of the closed-mesh-requiring "volume" mode. Plate mode girlies rise.

🫶 Example 22 — Returning all Combinations That Have Given Object As a Member 🫶

search -above=1 -name example.s

Prints all combinations that have example.s as a member. This behavior is identical to the deprecated command dbfind.

💅 Example 23 — Returning the Full Path(s) of a Given Object 💅

search / -name example.s

Prints all paths to example.s. This behavior is identical to the deprecated command dbfindtree.

🌈 Example 24 — Verbose Reporting of Search Information 🌈

search allows for multiple levels of verbose reporting, and each one is giving more:

1. The first level reports the total number of items found.
2. The second level reports the boolean operator used at each step along the path.
3. The next, and final, level reports the primitive type of each object along the path.

You can supply increased verbosity two different ways: as a single flag with each 'v' indicating an elevated level (search -vv..), as well as stacked -v flags (search -v -v ..). Both work, pick your fighter.

mged>search -v /all.g ! -type comb

    /all.g/box.r/box.s
    /all.g/cone.r/cone.s
    /all.g/ellipse.r/ellipse.s
    /all.g/light.r/LIGHT
    /all.g/platform.r/platform.s
    /all.g/tor.r/tor
    [6] items found in search

First level of verbosity prints the total number of items found in the search. This is especially useful when coupled with the '-exec' flag, which may or may not print the number of items effected by the exec.

mged> search -vv /all.g ! -type comb
    OR
mged> search -v -v /all.g ! -type comb

    /u all.g/u box.r/u box.s
    /u all.g/u cone.r/u cone.s
    /u all.g/u ellipse.r/u ellipse.s
    /u all.g/u light.r/u LIGHT
    /u all.g/u platform.r/u platform.s
    /u all.g/u tor.r/u tor
    [6] items found in search

Second level of verbosity prints the total number of items found in the search as well as the boolean operators at each step along the path.

mged> search -vvv /all.g ! -type comb
    OR
mged> search -v -v -v /all.g ! -type comb

    /u all.g(c)/u platform.r(r)/u platform.s(arb8)
    /u all.g(c)/u box.r(r)/u box.s(arb8)
    /u all.g(c)/u cone.r(r)/u cone.s(tgc)
    /u all.g(c)/u ellipse.r(r)/u ellipse.s(ell)
    /u all.g(c)/u tor.r(r)/u tor(tor)
    /u all.g(c)/u light.r(r)/u LIGHT(ell)
    [6] items found in search

At max verbosity, it prints the total number of items found in the search, the boolean operators, and finally the primitive type of each object along the path. That's the full tea ☕

🍓 Example 25 — Operating on Sets of search Results 🍓

There are two available methods for working with sets of search results. Okay so:

Method one: the exec option, used in the following example to search for all regions below subtractions or intersections in the m35.g example model in BRL-CAD and draw the objects' wireframes in the display manager:

mged> search all.g -type region -and ( -below -bool - -or -below -bool + ) -exec draw "{}" ";"
mged> autoview

Method two: another possibility — especially useful for doing multiple sequential operations which would be awkward to write out in a single search line — is to assign the results of a search command to a Tcl variable.

To illustrate, let's randomize the colors of all regions in the "cab" assembly of the m35.g example model and then assign a glass shader with transparency as a follow-on step.

First, we collect the set of search results into a Tcl variable:

mged>  set glob_compat_mode 0
mged>  set search_results [search cab -type region]

Next we randomize the colors using Tcl's functionality (here we use random numbers and avoid any value less than 30 to keep objects more visible):

mged>  foreach i $search_results {attr set $i color [expr {int(rand()*225)+30}]/[expr {int(rand()*225)+30}]/[expr {int(rand()*225)+30}]}

Finally, we add transparency to the same regions:

mged>  foreach i $search_results {attr set $i shader {glass {tr 0.7 ri 1}}}

⚠️ Note ⚠️ Remember, when you're setting region colors, to check for the presence of a regionid_colortable attribute on the _GLOBAL object. If such a table is present (the m35.g sample model has one, for example) you need to remove that table (and for MGED wireframes, re-open the database) before the colors on the individual regions will "take": mged> attr rm _GLOBAL regionid_colortable

---

💀 DIAGNOSTICS 💀

Errors will be returned if parsing of the arguments fails, or if one of the primaries' evaluation functions returns an error. So like, if the words don't make sense, or the thing you asked for breaks — you'll get an error. No cap.

👑 AUTHOR 👑

Clifford Yapp

💖 COPYRIGHT 💖

okay so the legal bit, but make it cute: this software is Copyright (c) 2008-2026 United States Government as represented by the U.S. Army Research Laboratory. Portions Copyright 1990, 1993, 1994 The Regents of the University of California, per copyright and license information from OpenBSD and NetBSD. For more details see the copyright statements in search.c and search.h. 🫶✨

🐛 BUGS 🐛

bugs resulting from incorrect parsing of shell pattern expressions are the result of libbu's fnmatch — literally that’s the source, no cap. 💀

📬 BUG REPORTS 📬

got a bug or a problem? reports of bugs or problems should be submitted via electronic mail to devs@brlcad.org. 💌

---

and that’s the whole page, bestie! footer sign-off: source/version BRL-CAD, page SEARCH(nged), and the date isn’t shown on the footer line as given — no invented dates here, periodt. the trailing MANPAGE word is acknowledged too. 🎀✨💅