| Ticket UUID: | 3069454 | ||
| Title: | difference between bcc'ed and eval'ed regexp | ||
| Type: | Bug | Created on: | 2010-09-17 20:41:05 |
| Submitter: | msofer | Assigned to: | jan.nijtmans |
| Subsystem: | 43. Regexp | Severity: | Minor |
| Priority: | 8 | Last modified: | 2026-10-18 21:15:12 |
| Status: | Pending | Closed by: | nobody |
| Resolution: | Fixed | Closed on: | |
| Version: | 8.6.18, 9.0.5, 9.1.0 | ||
| Description: | ||||
the [regexp] compiler does option completion, but the normal command does not?
% regexp -n FoO dogfood
bad switch "-n": must be -all, -about, -indices, -inline, -expanded, -line, -linestop, -lineanchor, -nocase, -start, or --
while evaluating {regexp -n FoO dogfood}
% proc a {} {regexp -n FoO dogfood}; a
1
The completion feature is tested in regexpComp.test: 21.6-7 and 24.6-7
| ||||
| User Comments: | ||||
hobbs added on 2010-09-18 06:57:04:
Hmmm ... this seems to show that regexp itself is not consistent with standard Tcl option behavior, which is to allow uniq abbrs of options. Indeed, Tcl_RegexpObjCmd uses TCL_EXACT for getopts, whereas the compile cmd does a strcmp of len >= 2. It seems like it would be consistent to correct tclCompCmds.c to enforce the full -nocase, as regexp has behaved that way since 8.0, even if most Tcl commands allow abbr opts. Agreed? serhiy.storchaka added on 2026-10-10 20:15:39:
Still the same in 8.6, 9.0 and 9.1: TclCompileRegexpCmd() accepts any prefix of -nocase of at least 2 characters, while Tcl_RegexpObjCmd() requires the full option name. string compare, string equal, string map, string match, switch, lsearch and lsort all accept abbreviations of -nocase. Proposed fix in branch regexp-nocase-abbrev: instead of making the compiler exact, the command also accepts abbreviations of -nocase. This breaks nothing, since it only turns errors into successes. Other options still need their full names. Tests regexp-30.1 to 30.3. jan.nijtmans added on 2026-10-12 20:00:26:
Actually, I have a problem with some options within the same command being abbreviatable and others not. No other Tcl command does that. So, my proposal variant is: [e93dfd305ea29e3b]. In this specific case, I don't see any negative side-effect doing that. In general we should not advocate using abbreviated options, since it may cause incompatibilities if later options are added. But in manual typing in a shell, there's no harm, therefore many commands (especially when preceded with a minus-sign) allow that. We should - in my opinion - do the same here. serhiy.storchaka added on 2026-10-12 20:37:46:
That is a decision for you. I only considered variants for
Note that with all options abbreviatable some prefixes are ambiguous:
Two related mismatches between compiled code and the command, where the
compiler accepts an abbreviation that the command rejects as ambiguous:
[1ae976e237] ( jan.nijtmans added on 2026-10-18 21:15:12:
Merged to [43345b959d|trunk] and core-9-0-branch. Merge to 8.6 still to be done | ||||