UNIX for Dummies Questions & Answers

I'm afraid you refuse to face the evidence so I'm giving up trying to help you understanding where your reasoning fails and why this isn't academic.

There are people that are grateful they are teach something and other people that can't accept being wrong. Looks like you want to be in the second category.

It reminds me those people claiming landing on the moon was faked. I never waste my time discussing with them.

I think we had better agree to differ.

When I come across it again I'll gather evidence and re-post. If you manage to prove that no version of unix or Linux ever exhibits this anomolous behaviour, please re-post.

This has been entertaining if nothing else and I bookmarked some useful reference works along the way (many not posted in this thread).
I even fished some of my archive unix manuals out of storage where I could not find a copy on the Internet. I also re-visited the "find ... -exec" version which crashes unix to find out when they changed the implementation.

I haven't worked on every version of unix but I have worked on rather too many unix variants to believe in standard behaviour!

Thanks for the debate.

methyl

I already demonstrated it many times.
It is impossible for a command (find) to process something differently (the file names with embedded spaces) depending on something (the quotes) there is no way for the command to know about (because the quotes have been stripped by the shell before passing the curly braces argument to the command to be run later).

I hope I'm not missing something already cleared/explained, but, as far as the filenames with embedded IFS characters are concerned (a space in the example below), and as already mentioned (see note for embedded {} usages before in the thread), a {} quoting might be needed, depending on the syntax used:

Code:

zsh-4.3.10[t]% touch 'a b'                          
zsh-4.3.10[t]% ls   
a b
zsh-4.3.10[t]% find -type f -exec sh -cx 'f={}'  \; 
+ f=./a
+ b
sh: b: command not found
zsh-4.3.10[t]% find -type f -exec sh -cx 'f="{}"'  \;
+ f='./a b'

And, of course, you can write if differently;

Code:

zsh-4.3.10[t]% find -type f -exec sh -cx 'f=$1' inline  {} \; 
+ f='./a b'

(Okay I know I signed off from this thread). Interesting radoulov. Looks different from issues with say renaming files using embedded {} syntax where this syntax is valid: "find .... -exec mv {} {}.txt".

radoulov: the syntax you use in your first examples is a different case than the one this thread is about. (Glad to agree with Methyl on this )

It also breaks the standard a couple of times so is in the undefined behavior area. i.e. it might work or not depending on the find implementation.

POSIX states:

- the path must not be empty
- the curly braces must appear alone to be processed

It will work in a Gnuish environment but with a POSIX compliant shell and find you might get the following:

Code:

$ find -type f -exec sh -cx 'f={}'  \; 
find: illegal option -- t
find: [-H | -L] path-list predicate-list
$ find . -type f -exec sh -cx 'f={}'  \;
+ f='{}'

The last example is a portable way to achieve the same, although the inline trick might be puzzling and is unnecessary:

Code:

$ find . -type f -exec sh -cx 'f=$1' inline  {} \;
+ f='./a b'
$ find . -type f -exec sh -cx 'f=$0' {} \;
+ f='./a b'

---------- Post updated at 11:57 ---------- Previous update was at 11:51 ----------

Too bad this syntax breaks POSIX twice too:
- if {} appear more than once, behavior is unspecified
- it is processed if passed as a two characters argument

Sorry,
I didn't understand that the thread was about the standard, I was replying to this statement:

Anyway, the first point (about the path) is irrelevant in this case, it was a quick and dirty way to demonstrate the point.

As I already said, the poit about the predicate is irrelevant and I didn't consider the standard for this example.

Well,
it could be necessary if, for some reason, you need to name your script/label your code (and use that name/label later).