Prev: /var/log/kdm.log file now 7.3GB HELP
Next: almost luck
From: Rockinghorse Winner on 29 Dec 2009 10:17 Eef Hartman <E.J.M.Hartman(a)tudelft.nl> writes: >Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote: >> Not exactly sure - it should barf the same way. You're seeing >> a shell expansion of the star character. >Newer shells DO leave the * alone when there are NO matching files. >So probably the OP changed to a directory in which there are no >.mp3 files present. >-- >******************************************************************* >** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** >** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-278 82525 ** >******************************************************************* What I conclude is that *find* does not handle multiple files on the command line well. You cannot type 'find . -name 01.mp3 02.mp3'. And essentially, that is what the shell is doing when you use the * wildcard char. -- Powered by Linux 2.6.31.6-166 Fedora 12 In rotation: Pacific Ocean Blue (D. Wilson) 2.6.31.5-0.1 OpenSUSE 11.2 "Hug your cat today" 2.6.24-16 Mint Elyssa
From: Eef Hartman on 29 Dec 2009 11:01 Rockinghorse Winner <rwinner(a)8600.com> wrote: > What I conclude is that *find* does not handle multiple files on the command > line well. You cannot type 'find . -name 01.mp3 02.mp3'. And essentially, > that is what the shell is doing when you use the * wildcard char. The -name option has a SINGLE argument. For multiple files you need multiple -name options, like find <path> -name 01.mp3 -o -name 02.mp3 ... (note the -o, to show that the options should be "or"d, the default in find is AND for mutiple options, so then you would be looking for a filename that is BOTH 01.mp3 as well as 02.mp3 at the same time, which of course will return NO matches at all). Because of the rather peculiar syntax of find, the only place an UNprotected wildcard (*, ?, [ranges] etc) can be used is in the DIRECTORY path(s) part of the commandline (and yes, there they work, i.e: find /usr/*bin -name <somefile> will look in both /usr/bin as well as as /usr/sbin). In a 64 bits system, while searching for a certain library, the command find /lib* /usr/lib* -name <library> is often very usefull. -- ******************************************************************* ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-278 82525 ** *******************************************************************
From: Rockinghorse Winner on 29 Dec 2009 20:14 Eef Hartman <E.J.M.Hartman(a)tudelft.nl> writes: >In a 64 bits system, while searching for a certain library, the command > find /lib* /usr/lib* -name <library> >is often very usefull. And I take it, in that instance, 'or' is the default. -- Powered by Linux 2.6.31.6-166 Fedora 12 In rotation: Pacific Ocean Blue (D. Wilson) 2.6.31.5-0.1 OpenSUSE 11.2 "Hug your cat today" 2.6.24-16 Mint Elyssa
From: Moe Trin on 30 Dec 2009 14:58
On Tue, 29 Dec 2009, in the Usenet newsgroup alt.os.linux.suse, in article <F4ednbfW5vsXgKfW4p2dnAA(a)giganews.com>, Rockinghorse Winner wrote: >What I conclude is that *find* does not handle multiple files on the >command line well. You cannot type 'find . -name 01.mp3 02.mp3'. And >essentially, that is what the shell is doing when you use the >* wildcard char. You've got to be a little more careful in mixing terms. The older form of the man page showed "find [path...] [expression]" and the convention is that arguments _shown_ within square brackets can be repeated - meaning 'find /path1 /path2 /path3 expression1 expression2' and so on. (Now, there are several specific options that can precede the path variable[s], but the idea remains the same.) The 'expression' part of the command begins with variables that begin with a dash, open parentheses ( '(' ) or bang ( '!' ). The expressions variables are "logically AND'ed" unless within parentheses and specified to be -o indicating 'logically OR'ed. For example find /[behlsv]* \( -type f -o -type d \) -perm -002 would be interpreted with the first term ( /[behlsv]* ) expanded by the shell to be directories in / that begin with those letters, the second "term" being either type -f or type -d (the two combined by the parentheses, and ordered by the -o to be OR'ed), AND having the world writable bit set in the permissions. The -name option wants a single variable - but that variable may be a regular expression which 'find' will evaluate/expand. The problem you've got to watch for is that the shell tries to expand things as well, which is why the 'find' man page specifically warns to protect (either by quoting, or escaping the wildcard characters). 'find' can be extremely frustrating, or incredibly useful. And just to warn you, this is GNU find - because not all POSIX find commands (example - other find commands found in UNIX or BSD) behave in the same manner/have the same options. Old guy |