bin/164070: cd built-in in /bin/sh doesn't report cd(1) errors in an intuitive/correct manner

[Garrett Cooper]

>Number:         164070
>Category:       bin
>Synopsis:       cd built-in in /bin/sh doesn't report cd(1) errors in an intuitive/correct manner
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 12 22:40:03 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Garrett Cooper
>Release:        10-CURRENT
>Organization:
iXsystems, Inc.
>Environment:
FreeBSD streetfighter.ixsystems.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r229730M: Fri Jan  6 14:03:26 PST 2012     gcooper at streetfighter.ixsystems.com:/usr/obj/usr/src/sys/STREETFIGHTER  amd64
>Description:
/bin/sh doesn't report proper errors when cd'ing to an invalid path (in this case a file, not a directory):

$ sh -c 'cd /usr/src/Makefile'
cd: /usr/src/Makefile: No such file or directory

bash does the right thing:

$ bash -c 'cd /usr/src/Makefile'
bash: line 0: cd: /usr/src/Makefile: Not a directory

$ svn status /usr/src/bin/sh/
$

The bash reported error matches fchdir(2) semantics, whereas it appears that the sh reported error matches the chdir(2) semantics:

     [ENOENT]           The named directory does not exist.

..

     [ENOTDIR]          The file descriptor does not reference a directory.

If it is as I suspect and bash is using fchdir whereas sh is using chdir, bash is also using less error prone/security conscious logic.
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: