Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Change tcsh's default no match behavior UNIX
tcsh will consider it an error if it can't find a file matching an expression, and instead of executing it, it will print [cmd]: No Match. This makes it difficult to do things like:
find . -name [Mm]ac*
which works in bash (I do that a lot on linux as bash is the default shell). It takes some effort to properly escape the bracketed area, and I normally don't want to quote everything.

Another example is when typing URLs - the ? is used as a separator and results in the same error. To change tcsh's behavior, simply type:
set nonomatch
This will tell tcsh to NOT consider expressions with wildcards that don't match any file an error. Most apps will tell you if things are actually missing, but in the rest of the cases where the characters are intentional, it will work.

[Editor's note: I have not tried this myself, but I do have a question on it -- anyone know how to UNSET this option once you've set it?]
    •    
  • Currently 3.20 / 5
  You rated: 5 / 5 (5 votes cast)
 
[7,198 views]  

Change tcsh's default no match behavior | 9 comments | Create New Account
Click here to return to the 'Change tcsh's default no match behavior' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Alas we've got this backwards
Authored by: el bid on Mar 14, '02 11:54:12AM

The reason that tcsh complains "No Match" is that same reason the find command as quoted here won't work in bash.

Let's get this straight.

The asterisk in the line:

find . -name [Mm]ac*

...is an invitation to the shell (not to the find command) to glob out the expression _before_ passing it to find. Which isn't what we want to do. And incidentally the [Mm] part of the expression does nothing here, as if you ask the filesystem if there's a file called Mac it will tactfully say yes, even if you actually called it mac. This case-blindness is a, er, feature of HFS+ that we'd better not go into here, as I might get rather cross.

If we don't want the shell (bash or tcsh) to glob out the expression the correct thing in either case is to wrap it in quotes. So:

find . -name "mac*"

... will do what we need. No need at all to mess with the tcsh defaults.

This assumes, of course, that find knows how to do its own globbing, which it does. I mention this because it can bite you in the case of tar. Most proprietory tars can't glob, so:

tar cvf /dev/tape "*.tobebackedup"

...mostly won't work. GNU tar (hurrah!) does the right thing here, however.

--
el bid



[ Reply to This | # ]
Alas we've got this backwards
Authored by: el bid on Mar 16, '02 06:53:04AM
tar cvf /dev/tape "*.tobebackedup"

...mostly won't work. GNU tar (hurrah!) does the right thing here, however.

And just to prove that a guy who's been doing UNIX for ten years can also get it backwards, I've managed to do just that. If you want to save files called this.tobebackedup and that.tobebacked up you do of course want the shell to glob your asterisk, so this is exactly where you wouldn't use quotes. (and of course this will work with any tar, GNU or not).

]]BLUSH[[

What I meant to say was to use quotes to prevent globbing when you're using tar to look into a tarball. Eg, when listing it:

tar tv "*.tobebackedup"

...which is, AFAIK, GNU specific.

Perhaps we can just pretend that the c instead of the t was a slip of the fingers.

--
el bid


[ Reply to This | # ]
Alas we've got this backwards
Authored by: kwenzel on Mar 16, '02 10:40:07AM

Actually, this will work in bash, if there's no file in the CWD that matches the expression. Upon executing:

find . -name curry*

the file ./tmp/curry_comb.jpg will be successfully located - so long as no file matching curry* exists in the CWD.

Having pointed this out, there's still no excuse to expose expressions on the command line.



[ Reply to This | # ]
Unset & case insensitive
Authored by: Mithrandir on Mar 14, '02 01:23:56PM

use unset to UNSET a shell variable. Also using set from the command line will not be remembered the next time you open a shell.

As for the case insensitive issue. HFS+ is in fact case insensitive but most (if not all) of the BSD tools still distinguish between case. It has been my experience that something like: find . -name "mac*" will NOT find a file called "Mac" even though the filesystem doesn't care. Yes I am using HFS+ not UFS.

Don't be fooled by a case insensitive filesystem...

M



[ Reply to This | # ]
Unset & case insensitive
Authored by: el bid on Mar 15, '02 03:49:29AM
As for the case insensitive issue. HFS+ is in fact case insensitive but most (if not all) of the BSD tools still distinguish between case.

Apologies to all for shooting my mouth off here and not really understanding the issue. I will obviously have to investigate this further.

But isn't this in principle a rather _worse_ situation than the one I described? The BSD tools and the filesystem _disagreeing_ about the names of files?

--
el bid


[ Reply to This | # ]
Unset & case insensitive
Authored by: el bid on Mar 15, '02 03:51:38AM
As for the case insensitive issue. HFS+ is in fact case insensitive but most (if not all) of the BSD tools still distinguish between case.

Apologies to all for shooting my mouth off here and not really understanding the issue. I will obviously have to investigate this further.

But isn't this in principle a rather _worse_ situation than the one I described? The BSD tools and the filesystem _disagreeing_ about the names of files?

--
el bid


[ Reply to This | # ]
Unset & case insensitive
Authored by: el bid on Mar 15, '02 03:55:29AM

I have absolutely no idea why this response appears twice. I only wrote it once; only submitted it once.

Dare I suggest there may be a bug in MacHints? Possibly involving the server's response to the use of the Back function in the browser (mine's OmniWeb).

--
el bid



[ Reply to This | # ]
controlling glob-ing
Authored by: hayne on Mar 14, '02 01:35:06PM

As 'el bid' has already responded, the correct way to do such things as your 'find' example is by quoting the meta-characters (*, ?, etc). There is no way arround this if what you want is for the pattern matching to be done by 'find' instead of by the shell.

But if you really want to stop the shell from doing the pattern matching, you can set the shell variable 'noglob' via the command:
set noglob
To revert back to the usual state where the shell does the pattern matching:
unset noglob
(The 'unset' command is the answer to the editor's query about how to turn off the 'nonomatch': unset nonomatch )

And, by the way, if you want to see the result of the shell's pattern matching, the usual recommendation is to do a command like 'ls' using the same pattern before trying it with something more dangerous (like 'rm') or time-consuming. But tcsh supplies an alternative: you can get it to expand your command line in place by means of the "expand-glob" editor command. To use this, you type your command (e.g. ls g*.html ) and then (before hitting return) type control-X and then *



[ Reply to This | # ]
.
Authored by: Mithrandir on Mar 15, '02 11:49:03PM
But isn't this in principle a rather _worse_ situation than the one I described? The BSD tools and the filesystem _disagreeing_ about the names of files?

Certainly makes you wonder...

M


[ Reply to This | # ]