I created and added the following bash function to my bash config script a few weeks ago:
cd() {
if [ "$PS1" ]
then
if [ "$1" ]
then pushd "$1" >/dev/null && ls $LS_OPTIONS
else pushd >/dev/null && ls $LS_OPTIONS
fi
else
if [ "$1" ]
then pushd "$1" >/dev/null
else pushd >/dev/null
fi
fi
}
I haven't had problems with it until recently when it has prevented some other commands from behaving properly and I have to comment out the function. For example, when trying to clone a heroku app, I got:
environment: line 8: pushd: -P: invalid number
pushd: usage: pushd [-n] [+N | -N | dir]
environment: line 8: pushd: -P: invalid number
pushd: usage: pushd [-n] [+N | -N | dir]
environment: line 10: pushd: no other directory
And when trying to use rbenv to install ruby, it would throw an error, something like "pwd did not return a directory", until I commented out this function.
I know just enough bash to be dangerous and I'm not sure what in the function might be causing the headaches.
Overriding
cdmeans that any code that expects the "regular"cdwill use your function instead. The first problem is the that your function assumes the first argument will be the directory, but your error indicates that some uses are passing different options (like-P) as the first argument. You can fix this rather easily, simply by passing all arguments instead of just the first one. This also handles the zero argument case at the same time.However, the
-Pin the error message indicates the next problem.cdandpushddon't take the same options, so code assuming it is callingcdcan pass options thatpushddoesn't recognize.pushd, however, can add to the directory stack without changing the directory, so you could use both commands in your function. Thebuiltincommand lets you call the originalcdwithout getting stuck in infinite recursion.It may be simpler, though, to acknowledge that you really want to override
pushdand train yourself to use it instead ofcd.