I'll copy my answer from the original bug here, for reference. Feel free to make this comment not private, I only made it so because the text above is. --- 8< --- > > - [...] . | (cd /my_backup_patch && tar -xf - [...]"). > Isn't pushd and popd better? The pushd/popd builtins are different. Interestingly, the (cd ... && ...) way does things how a cd executable would do it: change to the directory in a new process, which doesn't influence the parent (which is why I use it here -- no need to remembed to popd later on). > > I can't think of any problem these executables would solve, the shells need > > them built-in anyway for their main purpose of e.g. changing the working > > directory in the shell. IMO, this is a case where the standard needs to be > > fixed rather than that it should be followed by the letter. > > Nils, did you send report for this? Or should I? I wouldn't have an idea whom to contact about this.
$ type -p alias bg cd command false fc fg getopts jobs kill newgrp pwd read true umask unalias wait /usr/bin/newgrp So only newgrp is not bash builtin $ which alias bg cd command false fc fg getopts jobs kill pwd read true umask unalias wait 2>/dev/null /usr/bin/false /usr/bin/kill /usr/bin/pwd /usr/bin/true Only false, kill, pwd and true has alternatives. Need to add alternatives for: alias bg cd command fc fg getopts jobs read umask unalias wait
This will add more chaos to usage of `which' command.
Fixed in bash-4.2.28-2.fc18.
(In reply to Nils Philippsen from comment #1) > I'll copy my answer from the original bug here, for reference. Feel free to > make this comment not private, I only made it so because the text above is. > > --- 8< --- > > > > - [...] . | (cd /my_backup_patch && tar -xf - [...]"). > > Isn't pushd and popd better? > > The pushd/popd builtins are different. Interestingly, the (cd ... && ...) way > does things how a cd executable would do it: change to the directory in a new > process, which doesn't influence the parent (which is why I use it here -- no > need to remembed to popd later on). > > > > I can't think of any problem these executables would solve, the shells need > > > them built-in anyway for their main purpose of e.g. changing the working > > > directory in the shell. IMO, this is a case where the standard needs to be > > > fixed rather than that it should be followed by the letter. > > > > Nils, did you send report for this? Or should I? > > I wouldn't have an idea whom to contact about this. This notion of changing the POSIX standard was attempted today, with a result of no change in status quo; the shims are still required. "This was discussed during the May 23, 2013 conference call. XRAT section C.1.7 clearly states why the authors of this section of the standard decided to require these built-ins to be exec-able. We do not believe that the arguments presented in this change request override the concerns stated by the original authors. Therefore, we reject this proposed change." http://austingroupbugs.net/view.php?id=698#c1626 For reference, c.1.7 states: "There were originally three justifications for allowing the omission of exec-able versions: It would require wasting space in the file system, at the expense of very small systems. However, it has been pointed out that all 16 utilities in the table can be provided with 16 links to a single-line shell script: $0 "$@" It is not logical to require invocation of utilities such as cd because they have no value outside the shell environment or cannot be useful in a child process. However, counter-examples always seemed to be available for even the most unusual cases: find . -type d -exec cd {} \; -exec foo {} \; (which invokes "foo" on accessible directories) ps ... | sed ... | xargs kill find . -exec true \; -a ... (where "true" is used for temporary debugging) It is confusing to have a utility such as kill that can easily be in the file system in the base standard, but that requires built-in status for the User Portability Utilities option (for the % job control job ID notation). It was decided that it was more appropriate to describe the required functionality (rather than the implementation) to the system implementors and let them decide how to satisfy it. On the other hand, it was realized that any distinction like this between utilities was not useful to applications, and that the cost to correct it was small. These arguments were ultimately the most effective." http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html
I really do not think it was a good idea to introduce cd and the like as external commands. This is going to bite many people with limited knowledge about shells.
This change has caused issues with ksh[1]. `builtin` keyword works differently in bash and ksh, that's why `/usr/bin/cd` that is provided by bash and defined as: #!/usr/bin/sh builtin cd "$@" does not work with ksh. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1721048