Return to Answer

That's quite absurd and that's why no shell is implementing it in its default mode.

The standard's rationale and its illustrating example suggest that this was a botched attempt to have a regular built-in associated with a path, and let the user override it by having its own binary appear before it in PATH (eg. a printf built-in associated with /usr/bin/printf could be overridden by the /foo/bin/printf external command by setting PATH=/foo/bin:$PATH).

However, the standard did not end up requiring that, but something completely different (and also useless and unexpected).

You can read more about it in this bug report. Quoting from from the final accepted text:

Many existing implementations execute a regular built-in without performing a PATH search. This behavior does not match the normative text, and it does not allow script authors to override regular built-in utilities via a specially crafted PATH. In addition, the rationale explains that the intention is to allow authors to override built-ins by modifying PATH, but this is not what the normative text says.

FWIW, I don't think there's any shell implementing the revised requirements from the accepted text, either.

That's quite absurd and that's why no shell is implementing it in its default mode.

The standard's rationale and its illustrating example suggest that this was a botched attempt to have a regular built-in associated with a path, and let the user override it by having their own binary appear before it in PATH (eg. a printf built-in associated with /usr/bin/printf could be overridden by the /foo/bin/printf external command by setting PATH=/foo/bin:$PATH).

However, the standard did not end up requiring that, but something completely different (and also useless and unexpected).

You can read more about it in this bug report. Quoting from from the final accepted text:

Many existing implementations execute a regular built-in without performing a PATH search. This behavior does not match the normative text, and it does not allow script authors to override regular built-in utilities via a specially crafted PATH. In addition, the rationale explains that the intention is to allow authors to override built-ins by modifying PATH, but this is not what the normative text says.

FWIW, I don't think there's any shell implementing the revised requirements from the accepted text, either.

That's quite absurd and that's why no shell is implementing it in its default mode.

That's probably up to shell & standard lawyers to determine, but my interpretation is that it was a botched attempt to have the regular built-ins associated with a path, and let the user override eg. printf by having their own printf implementation in /foo/bin and then setting PATH=/foo/bin:$PATH. The rationale and its illustrating example seem to confirm that.

However, the standard did not end up requiring that, but something completely different (and also useless and unexpected).

You can read more about it in this bug report. Quoting from from the final accepted text:

Many existing implementations execute a regular built-in without performing a PATH search. This behavior does not match the normative text, and it does not allow script authors to override regular built-in utilities via a specially crafted PATH. In addition, the rationale explains that the intention is to allow authors to override built-ins by modifying PATH, but this is not what the normative text says.

FWIW, I wasn't able to find any shell implementing the requirements from that, either.

That's quite absurd and that's why no shell is implementing it in its default mode.

The standard's rationale and its illustrating example suggest that this was a botched attempt to have a regular built-in associated with a path, and let the user override it by having its own binary appear before it in PATH (eg. a printf built-in associated with /usr/bin/printf could be overridden by the /foo/bin/printf external command by setting PATH=/foo/bin:$PATH).

However, the standard did not end up requiring that, but something completely different (and also useless and unexpected).

You can read more about it in this bug report. Quoting from from the final accepted text:

Many existing implementations execute a regular built-in without performing a PATH search. This behavior does not match the normative text, and it does not allow script authors to override regular built-in utilities via a specially crafted PATH. In addition, the rationale explains that the intention is to allow authors to override built-ins by modifying PATH, but this is not what the normative text says.

FWIW, I don't think there's any shell implementing the revised requirements from the accepted text, either.

That's quite absurd and that's why no shell is implementing it in its default mode.

That's probably up to shell & standard lawyers to determine, but my interpretation is that it was a botched attempt to have the regular built-ins associated with a path, and let the user override eg. printf by having their own printf implementation in /foo/bin and then setting PATH=/foo/bin:$PATH. The rationale and its illustrating example seem to confirm that.

However, the standard did not end up requiring that, but something completely different (and also useless and unexpected).

You can read more about it in this bug report. FWIW, I wasn't able to find any shell implementing the requirements from the final accepted text there, either.

That's quite absurd and that's why no shell is implementing it in its default mode.

That's probably up to shell & standard lawyers to determine, but my interpretation is that it was a botched attempt to have the regular built-ins associated with a path, and let the user override eg. printf by having their own printf implementation in /foo/bin and then setting PATH=/foo/bin:$PATH. The rationale and its illustrating example seem to confirm that.

However, the standard did not end up requiring that, but something completely different (and also useless and unexpected).

You can read more about it in this bug report. Quoting from from the final accepted text:

Many existing implementations execute a regular built-in without performing a PATH search. This behavior does not match the normative text, and it does not allow script authors to override regular built-in utilities via a specially crafted PATH. In addition, the rationale explains that the intention is to allow authors to override built-ins by modifying PATH, but this is not what the normative text says.

FWIW, I wasn't able to find any shell implementing the requirements from that, either.