; find /tmp -type d -exec ls -ld {} +
syntax error
; find /tmp -type d -exec ls -ld '{}' +
drwxrwxrwt+ 1 sysadmin root 0 2010-03-16 17:01 /tmp
; echo $version
1.7.1 $Release: @(#)rc 1.7.1 2003-07-17 $
I think you'll get the same or similar error with es.
As already demonstrated in the older thread:
% touch a\ b
% find . -type f -ls
4222124650680077 0 -rw-r--r-- 1 sysadmin None 0 Mar 16 21:16 ./a\ b
% find . -type f -exec sh -c 'f={}' - \;
-: b: command not found
% find . -type f -exec sh -c 'f="{}"' - \;
%
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:
$ 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:
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.
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.
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.
I think that was the point I was making earlier. Because of the 1990's divergence of the extant unix flavors, I don't see that knowing linux find semantics cold (or any other find implementation) is any sort of guarantee that a given semantic nuance will carry over somewhere else.
I still post ll instead of ls -l because I learned it first. Long ago. A lot of unixes do not have ll natively.
@methyl: I still believe this is not technically possible but the details you are providing are interesting.
One of the reasons I was denying any possibility for the quotes to be useful is that all know shells are removing them before passing them to the find command. This is defeating any usefulness with embedded spaces in filenames as there aren't spaces yet when the command is called. As you are telling this was occurring in a crontab context, it might be possible that an exotic/early cron implementation by DRS/NX would have not used a shell to interpret the command line but simply execute the line as is. I'm not aware of such weird implementation but I'm open to that possibility. In that case, and only in that one, the single quotes would have been received by the find command. Another hurdle is that, as far as I remember, System V find (DRS/NX was SVR2/3/4 based) was only expanding the curly braces when alone as argument but that wouldn't be the case when the quotes are passed untouched. Let's assume this second objection is false because of a specific customization. All find and rm implementations are properly handling their arguments so do not need quotes anyway. The only reason where these surviving quotes would have had an effect would have been a "rm" wrapper that wouldn't properly expands its arguments, like:
#!/bin/sh
# broken rm implementation
/bin/rm $*
That's a lot of oddities for a single system ...
About experience as you are asking, in the last 26 years I have been working in various expertise positions (support, training, development, consultancy) with many Unix releases including Unix version 7 (TNIX), 4.2BSD (Utek), Minix, Ultrix, HP-UX, DG-UX, AIX, SVR3 (Utek V), Xenix, SCO, OSF/1, IRIX, SunOS 4 and 5 (Solaris) all versions and Gnu/Linux most mainstream distributions.
Of course, none of these did/do exhibit in their standard configuration the '{}' feature you are supporting.