![]() ![]() This is assuming that md.tpr is a regular file that should be found. type f -name md.tpr -exec bash -O nullglob -O dotglob -c ' So, instead of what you're currently doing, consider find. The reason for this is given in the question/answer " Why is looping over find's output bad practice?". I would urge not to do that, and instead to do that processing in the actual find command itself. You additionally say that you want to list the files matching *.e* for "further processing". In short, you can't call ls directly with -execdir or -exec and give it a filename globbing pattern. When the patterns don't match anything in the current directory, the pattern will be handed to ls as it is, and since ls does not expand globbing patterns by itself, it would fail to list any files. This is most likely your issue with your last find command that only seems to be able to work correctly from your home directory, probably because your home directory contains files matching the pattern (. The ls utility does not do expansions of filename globbing patterns by itself but relies on the shell to have done that already. This leads to, in your find command, that ls gets the unexpanded pattern *.e* as its argument. When the bash shell can't find a file that matches a given globbing pattern, it leaves the pattern unexpanded. Very different and do not match the same strings! Remember, GLOBS ARE NOT REGEXES - the glob ".*" and the regex ".*" are Usually this just means putting your globstrings in single quotes like this find /path -iname '*.txt' To prevent the shell from tampering with globs before find sees them, escape the globs with appropriate shell metacharacter quoting. This is almost certainly not what you want! So using globs this way means that find will behave differently depending on the content of the current directory. So at that point, the find command (which understands globs, remember) will output the names of all files it finds under /path that match the glob. The find command never sees the glob if this happens, the shell has expanded it out of existence.īut if there are no files in the current directory that match the glob, the shell shrugs its metaphorical shoulders and passes the glob unchanged to find. If it finds any, it substitutes the names of all the matching files for the glob, and then calls the find command. The first thing that happens is the shell attempts to find all files that match *.txt in the current directory. But find is a super duper mega power user tool that you can very easily hurt yourself with!Įxample: when you do the command find /path -iname *.txt This is unusual - most commands are NOT capable of globbing and rely entirely on the shell to expand globs. It doesn't work unless it's done from $HOME.īoth the find command and the shell are capable of file globbing. I use bash 3.2.25 (old but I don't have admin rights on that system).Īlso, interestingly, if I do find ~ -name. ![]() Any ideas? Or am I completely off the track? Now, I was able to solve this problem in a much less elegant way but it just baffled me why globbing and wildcards wouldn't work here. Just as a sanity check, I did -execdir pwd and it prints what it should, so it appears that it's a problem with globbing, as those *.e* files do exist in the directories listed with this test. The error I get when running the above command is: ls: *.e*: No such file or directory It appears that globbing is not working when passed to -exec or -execdir. ![]() I tried a few variants of this command and some others (including single quoting the command passed to -execdir or passing it as sh -c 'ls *.e*' or eval 'ls *.e*' to name a few). I needed to list them (for further processing) using the following: find. I tried finding some files ( *.e*) that are in the same directory as another file ( md.tpr). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |