Shell Programming and Scripting

FWIW - there is no one implementation of find, or ls or xargs. Solaris has oddities buried in its core utils code, as does linux, HPUX and so on. The reason for this is usually cited as backwards compatibility.

So, reading Solaris find code tells you nothing about GNU find, for example. Not to mention the "family tree" differences in UNIX.

Granted. Thanks for reminding these is at least one of these beasts around. Plan 9 CLI does indeed interpret the curly braces. I forgot that but I doubt the open poster is using such an exotic shell.

This doesn't change my point single quoting curly braces alone has no effect whatsoever with find and embedded spaces and your second example is precisely supporting it:

Code:

$ find . -type f -ls
1096125622    0 -rw-r--r--   1 jlliagre jlliagre        0 Mar 16 22:01 ./a\ b
$ gfind . -type f -exec bash -c f={} - \;
-: b: command not found
$ gfind . -type f -exec bash -c 'f={}' - \;
-: b: command not found

You need to quote the quotes themselves for the exec subcommand to get them but this is a different issue and it appears with any shell.

---------- Post updated at 22:18 ---------- Previous update was at 22:12 ----------

Hmm, a closer look at the initial command makes me think it is broken anyway:

Code:

find /path -mindepth 3 -type d -exec rm -rf {} \;

There is a race condition. Find is at the same time exploring directories and removing them recursively. This can't work reliably and has nothing to do with embedded spaces in filenames.

Yes,
actually the example was a bit misleading (my fault), the file name doesn't matter in that case.

I just wanted to show that in some situations you need to quote the braces.

---------- Post updated at 10:25 PM ---------- Previous update was at 10:24 PM ----------

Yep,
and this was already pointed out.

Indeed, I missed posting #13. I was more (over)reacting to that {} myth being back on topic than following the thread. Alister got it definitely right.

@jilliagre

Welcome back to this debate. I enjoyed the previous one.
However I must quote myself:
I continue to be interested in variations in unix which would be relevant to writing portable shell script or diagnosis of failures.

Yet again we find ourselves not knowing what Operating System the O/P is using or what variation and vintage of "bash".
There is also uncertainty about whether this command behaved the same when run from cron or shell.
This lack of basic information in posts such as this implies that many people believe that all unix and Linux commands behave the same. They don't.
These are living Operating Systems which undergo continuous improvement and change.

On the point of {} or '{}' it is not a myth I still maintain that I have seen and repaired that problem before but cannot reproduce it in the modern Operating Systems which I have to hand. Quoting '{}' is even mentioned in current Linux "man find". A poster in this thread suggested '{}' as a solution.

I have cold build a wide variety of pre-unix O/S (including the original not-the-Mac OS/9), umpteen unix variants, mainstream manufacture unix, and assorted Linux systems.

I accept the quirks but also need to know about them.




radoulov post is very interesting and triggered a flashback to a mainstream manufacturer proprietary software suite which used to create directories and files according to whatever the user typed (complete with control codes and escape sequences). I'll play around with "find" and directories with duff names (rather than strictly files).

High methyl, you won't be surprised that I maintain {} vs '{}' in the context of the find command and filenames with spaces can't be but a myth in any present or past Unix or Unix like Operating System implementation.
Please don't confuse people again with gnu find (and POSIX find) manual pages which indeed mention '{}' but for a unrelated potential issue with exotic shells. This issue is not related in any way with embedded spaces.

@jlliagre
After the last debate ended I came across a diary entry about a replacement script I created to replace a manufacture-supplied one-line cron in DRS/NX following a spate of incidents when /tmp filled on multiple systems on multiple sites.
There was a pretty basic one-line "find ... exec rm {} \;" to remove files more than 7 days old. It failed with filenames containing spaces or non-printable characters.
You can guess the rest.

BTW: Before making sweeping statements what is your experience of DRS/NX , Unixware, AIX, RSX, Berkeley unix, and pure unix System V to name but a few? I don't count SunOS or Solaris in any of these categories.