A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1234 ====================================================================== Reported By: stephane Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1234 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Stephane Chazelas Organization: User Reference: Section: 2.13.1 Page Number: 2382 Line Number: 76212-76215 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2019-03-08 23:58 UTC Last Modified: 2019-03-12 22:37 UTC ====================================================================== Summary: in most shells, backslash doesn't have two meaning wrt pattern matching ======================================================================
---------------------------------------------------------------------- (0004319) stephane (reporter) - 2019-03-12 22:37 http://austingroupbugs.net/view.php?id=1234#c4319 ---------------------------------------------------------------------- Re: http://austingroupbugs.net/view.php?id=1234#c4306 > Lacking the ability to write a pattern in anything other than original > shell code reliably is too big a loss to suffer - there must be a reliable > way to access a variable pattern, reliably, and use it (fully functional). "loss" implies something that you had and that you no longer have. Again, that "essential" feature you couldn't do without is hardly implemented by any shell, not even yours (at least not in the NetBSD 7.1.2 test VM I have here). On the other hand, [*]* has been the way to match strings starting with * for almost 50 years (hence my "historical" reference to the Thomson shell, which the Mashey shell built open which the Bourne shell built upon which the Korn shell built upon, a subset of which POSIX specifies as sh). I avoid \ as a quoting operator whenever I can as \ is way too overloaded (as quoting operator (with several layers in shells with `...`), as escape sequence introducer, as line continuation, and again in most utilities called by the shell). Rather than case $x in (\?*) I prefer: case $x in ('?'*) Should I argue that pattern="'?'*" case $x in ($pattern) should match on strings that start with "?"? How about pattern='$var*' Should we ask for a second round of shell evaluation (which is what you're asking for \ hence Konrad's eval suggestion, why stop there?) on the content of a variable when that variable is used as a pattern (reminding me of the infamous wordexp(3)) Again, fnmatch() doing backslash handling is its own implementation of quoting as a poor man substitute to shell quoting (globs came from the shell, fnmatch() was an effort to bring it to other commands). It's only doing \, not "..." nor '...', possibly for simplicity and/or to align with regexps. Note that I'm not asking that POSIX prohibit that double backslash evaluation. It's too late, some shells are already doing it. Since bash, one can no longer do files='\x*'; ls -d $files and expect that to list the filenames that start with \x (not that anybody is likely to want to do that). What I'm saying is: allow it if you want, but do not mandate it. I'm not going to argue much longer, that's enough of a corner case, that I don't really care. If POSIX decides to mandate it, that p='\**'; echo $p should match files starting with *, OK (though I'll probably keep using the more portable [*]*), but at least leave p='\x*'; echo $p (that is where \ is not followed by a glob or \) unspecified so implementations can keep matching on '\x'* files and break fewer existing scripts. Issue History Date Modified Username Field Change ====================================================================== 2019-03-08 23:58 stephane New Issue 2019-03-08 23:58 stephane Name => Stephane Chazelas 2019-03-08 23:58 stephane Section => 2.13.1 2019-03-08 23:58 stephane Page Number => 2382 2019-03-08 23:58 stephane Line Number => 76212-76215 2019-03-11 02:42 kre Note Added: 0004296 2019-03-11 02:58 kre Note Edited: 0004296 2019-03-11 03:07 kre Note Edited: 0004296 2019-03-11 03:10 kre Note Added: 0004297 2019-03-11 03:16 kre Note Edited: 0004296 2019-03-11 03:23 kre Note Added: 0004298 2019-03-11 07:24 stephane Note Added: 0004300 2019-03-11 07:31 stephane Note Added: 0004301 2019-03-11 09:41 geoffclare Note Added: 0004303 2019-03-12 03:24 kre Note Added: 0004306 2019-03-12 03:37 kre Note Added: 0004307 2019-03-12 03:38 kre Note Deleted: 0004297 2019-03-12 09:13 Konrad_Schwarz Note Added: 0004309 2019-03-12 09:58 geoffclare Note Added: 0004310 2019-03-12 12:13 Don Cragun Note Edited: 0004306 2019-03-12 12:14 Don Cragun Note Edited: 0004306 2019-03-12 12:15 kre Note Added: 0004313 2019-03-12 12:16 Don Cragun Note Edited: 0004307 2019-03-12 12:23 kre Note Added: 0004314 2019-03-12 12:24 kre Note Edited: 0004314 2019-03-12 14:29 Konrad_Schwarz Note Added: 0004317 2019-03-12 14:56 kre Note Edited: 0004313 2019-03-12 14:58 kre Note Edited: 0004314 2019-03-12 15:11 kre Note Added: 0004318 2019-03-12 22:37 stephane Note Added: 0004319 ======================================================================
