find errors "paths must precede expression: %d" ..., "missingargument to `-exec'"
in [Shell]
|
Prev: find errors "paths must precede expression: %d" ..., "missing argument to `-exec'"
Next: Ya didnae ha' te use brackets. Be curly, Jimmeh!
From: Ed Morton on 5 Feb 2010 10:49 On 2/5/2010 9:29 AM, Ben Bacarisse wrote: > Ed Morton<mortonspam(a)gmail.com> writes: > >> On 2/5/2010 6:38 AM, Ben Bacarisse wrote: >>> lbrtchx(a)gmail.com writes: > <snip> >>>> # FIND DIRECTORY >>>> _FND_DIR=/UNIONFS/var >>>> >>>> # EXCLUDING (should be done in a loop and using awk) >>>> _XKLD="-noleaf -wholename '/proc' -prune -o -wholename '/media/sda1' -prune" >>>> >>>> #eval find ${_FND_DIR} ${_XKLD} -o -type f -printf '%s %d ' -exec md5sum -b {} \;> 2sort_md5sum.tmp >>>> #find: paths must precede expression: %d >>> >>> This, and all the subsequent errors, are caused by the eval. Why are >>> you using eval? It is quite rare in shell scripting and certainly not >>> needed when all you want to do is run a command. >> >> He wants to be able to store parts of the command in shell variables >> and then execute them together later. > > As the example illustrates, this gets messy using eval and there is > nothing in the line as posted that suggests eval is needed. If the > parts of the command are simply options and the like (as illustrated) > I don't see the need for it. Maybe a previous example showed why > eval is needed, but I missed that. In a previous thread the OP wrote: > I would like for the whole discriminating section: > ~ > -noleaf -wholename '/media/sda1' -prune -o -wholename '/proc' -prune > ~ > to be included in a parameter like this: > ~ > _XKLD="-noleaf -wholename '/media/sda1' -prune -o -wholename '/proc' -prune" > ~ > so that the previou statement looks like: > ~ > find ${_FND_DIR} ${_XKLD} -o -type f -printf '%T@,%A@,%C@,"%P"\n' > found.txt Ed.
From: Jon LaBadie on 5 Feb 2010 16:17 Ed Morton wrote: > On 2/5/2010 9:29 AM, Ben Bacarisse wrote: >> Ed Morton<mortonspam(a)gmail.com> writes: >> >>> On 2/5/2010 6:38 AM, Ben Bacarisse wrote: >>>> lbrtchx(a)gmail.com writes: >> <snip> >>>>> # FIND DIRECTORY >>>>> _FND_DIR=/UNIONFS/var >>>>> >>>>> # EXCLUDING (should be done in a loop and using awk) >>>>> _XKLD="-noleaf -wholename '/proc' -prune -o -wholename >>>>> '/media/sda1' -prune" >>>>> >>>>> #eval find ${_FND_DIR} ${_XKLD} -o -type f -printf '%s %d ' -exec >>>>> md5sum -b {} \;> 2sort_md5sum.tmp >>>>> #find: paths must precede expression: %d >>>> >>>> This, and all the subsequent errors, are caused by the eval. Why are >>>> you using eval? It is quite rare in shell scripting and certainly not >>>> needed when all you want to do is run a command. >>> >>> He wants to be able to store parts of the command in shell variables >>> and then execute them together later. >> >> As the example illustrates, this gets messy using eval and there is >> nothing in the line as posted that suggests eval is needed. If the >> parts of the command are simply options and the like (as illustrated) >> I don't see the need for it. Maybe a previous example showed why >> eval is needed, but I missed that. > > In a previous thread the OP wrote: > >> I would like for the whole discriminating section: >> ~ >> -noleaf -wholename '/media/sda1' -prune -o -wholename '/proc' -prune >> ~ >> to be included in a parameter like this: >> ~ >> _XKLD="-noleaf -wholename '/media/sda1' -prune -o -wholename '/proc' -prune" In the OP's specific example shown above, the single quotes (') are unneeded and I think are the only reason an eval is needed in the cmd line below. So simply recode the above as: _XKLD="-noleaf -wholename /media/sda1 -prune -o -wholename /proc -prune" and the run the find cmd below as is. Of course, other definitions of _XKLD might need some quoting and an eval. >> ~ >> so that the previou statement looks like: >> ~ >> find ${_FND_DIR} ${_XKLD} -o -type f -printf '%T@,%A@,%C@,"%P"\n' > found.txt > > Ed.
From: Kaz Kylheku on 6 Feb 2010 02:27
On 2010-02-05, Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-02-05, Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: >> A couple of other details: Why use {} round your variables? I find >> $XKLD simpler and more readable than ${_XKLD}. Second, what are all >> the initial # characters? Are they, too, from you newsreader when you >> paste output? Anyway, they confuse matters (at least they confuse me) >> so you might want to look at removing them. > > One of my coworkers does this habitually, I think because: > 1. It is *sometimes* necessary. A better habit is to quote variable expansions. Quoting is sometimes necessary depending on the /content/ of the variable. Braces are necessary based on the surrounding context; i.e. it's obvious by visual inspection when they are not necessary. command ${FOO} ${BAR} is completely stupid. You've wasted keystrokes on obviously superfluous syntax, and it still screws up if the expansion is subject to word splitting. > Having been burned at least once by "why does $FILE_bar not expand to > foo_bar", I am sympathetic. Quotes will take care of this: "$FILE"_bar. |