Why GNU find -execdir command behave differently than BSD find

It's not an endless looping, it's just GNU find reporting that echo died of a SIGPIPE (because the other end of the pipe on stdout has been closed when head died).

-execdir is not specified by POSIX. And even for -exec, there's nothing in the POSIX spec that says that if the command is killed by a SIGPIPE, find should exit.

So, would POSIX specify -execdir, gfind would probably be more POSIX conformant than your BSD find (assuming your BSD find exits upon its child dying of a SIGPIPE as the wording of your question suggests, FreeBSD find doesn't in my tests and does run echo in a loop for every file (like for GNU find, not endless)).

You may say that for most common cases, find exiting upon a child dying of SIGPIPE would be preferable, but the -executed command could still die of a SIGPIPE for other reasons than the pipe on stdout being closed, so exiting find for that would be borderline acceptable.

With GNU find, you can tell find to quit if a command fails with:

find . ... \( -exec echo {} \; -o -quit \)

As to whether a find implementation is allowed or forbidden to report children dying of a signal on stderr, here (with the usage of -execdir) we're outside the scope of POSIX anyway, but if -exec was used in place of -execdir, it seems that would be a case where gfind is not conformant.

The spec for find says: "the standard error shall be used only for diagnostic messages" but also says there:

Default Behavior: When this section is listed as "The standard error shall be used only for diagnostic messages.", it means that, unless otherwise stated, the diagnostic messages shall be sent to the standard error only when the exit status indicates that an error occurred and the utility is used as described by this volume of POSIX.1-2008.

Which would indicate that since find doesn't return with a non-zero exit status in that case, it should not output that message on stderr.

Note that by that text, both GNU and FreeBSD find would be non-compliant in a case like:

$ find /dev/null -exec blah \;; echo "$?"
find: `blah': No such file or directory
0

where both report an error without settng the exit-status to non-zero. Which is why I raised the question on the austin-group (the guys behind POSIX) mailing list.

Note that if you change your command to:

(trap '' PIPE; find -L /etc -execdir echo {} \; | head)

echo will still be run for every file, will still fail, but this time, it will be echo reporting the error message.

Now about filename vs /etc/filename vs ./filename being displayed.

Again, -execdir being not a standard option, there's no text that says who's right and who's wrong. -execdir was introduced by BSD find and copied later by GNU find.

GNU find has done some intentional changes (improvements) over it. For instance, it prepends file names with ./ in the arguments passed to commands. That means that find . -execdir cmd {} \; doesn't have a problem with filenames starting with - for instance.

The fact that -L -execdir doesn't pass a filepath relative to the parent directory is actually a bug that affects version 4.3.0 to 4.5.8 of GNU find. It was fixed in 4.5.9, but that's on the development branch and there hasn't been a new stable release since (as of 2015-12-22, though one is imminent).

More info at the findutils mailing list.

If all you want is print the base name of every file in /etc portably, you can just do:

find -L /etc -exec basename {} \;

Or more efficiently:

find -L ///etc | awk -F / '/\/\// && NR>1 {print last}
                          {if (NF > 1) last = $NF
                           else last = last "\n" $NF}
                          END {if (NR) print last}'

which you can simplify to

find -L /etc | awk -F / '{print $NF}'

if you can guarantee file paths don't contain newline characters (IIRC, some versions of OS/X had such files in /etc though).

GNUly:

find -L /etc -printf '%f\n'

As to whether:

find -exec echo {} \;

in the link you're referring to, is POSIX or not.

No, as a command invocation, that is not POSIX. A script that would have that would be non-compliant.

POSIX find requires that at least one path be given, but leaves the behaviour unspecified if the first non-option argument of find starts with - or is a find predicate (like !, or (), so GNU find behaviour is compliant, so are implementations that report an error (or treat the first argument as a file path even if it represents a find predicate) or spray red paint at your face, there's no reason POSIXLY_CORRECT would affect the find behaviour there.