inconsistent output for cd

[Tony Balinski]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: cygwin
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin' -DCONF_VENDOR='pc'
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H
-DRECYCLES_PIDS   -I.  -I/home/eblake/bash-3.2.15-13/src/bash-3.2
-I/home/eblake/bash-3.2.15-13/src/bash-3.2/include
-I/home/eblake/bash-3.2.15-13/src/bash-3.2/lib   -O2 -pipe
uname output: CYGWIN_NT-5.1 nycutbalil 1.5.24(0.156/4/2) 2007-01-31 10:57 i686
Cygwin
Machine Type: i686-pc-cygwin

Bash Version: 3.2
Patch Level: 15
Release Status: release

Description:
Sometimes cd echos the new directory, sometimes it doesn't. This makes
picking up a new directory in an overridden cd function painful:
cd () {
local oldd=$(pwd)
local newd=$(command cd "$@" 2>/dev/null 1>&2 && pwd 2>/dev/null)
# echo oldd="<$oldd>"
# echo newd="<$newd>"
if [[ $newd == "" ]]; then
echo "cd $* failed" 1>&2
elif [[ $oldd == $newd ]]; then
echo "cd $* - no change" 1>&2
else
# do extra cd processing here
command cd "$@" 2>/dev/null 1>&2
# do extra cd processing here
fi
}
In the assignment of newd, curiously, we get either one line or two!
newd should be just the new directory (the result of running built-in
cd in a subshell) but since it sometimes outputs a result (which seems
to bypass the output redirection), newd may end up with two separate
directories in two lines.

It seems like this extra output only occurs when CDPATH is used for the
cd operation. Also, popd and pushd also have similarly inconvenient
outputs. None of this is documented in the manual, and there appear to
be no options at all to turn this superfluous output off.

Repeat-By:
Try the above function, with the commented lines uncommented. Use it
to change to a directory in the CDPATH. Check the newd=... output.

Fix:
Don't use CDPATH! But that's a shame...


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: inconsistent output for cd

[Tony Balinski]

Quoting Chet Ramey <[EMAIL PROTECTED]>:

> > On Tue, 3 Apr 2007, Chet Ramey wrote:
> >
> > It is an interesting position for POSIX to take, given that in general
> > Unix is silent on success.
>
> It's the logical thing to do, considering the potential ambiguity that
> exists when you use a directory selected from CDPATH.  The illogical thing
> is that POSIX requires the output even when the shell is not interactive.
>
> > Does POSIX forbid an option "to turn this superfluous output off", as
> > Tony Balinski put it?
>
> Redirect stdout to /dev/null.  That's the conventional way to rid yourself
> of superfluous output.
>
This is where I find an inconsistency. With the function I gave,

  cd ()
  {
local oldd=$(pwd);
local newd=$(command cd "$@" 2>/dev/null 1>&2 && pwd 2>/dev/null);
echo oldd="<$oldd>";
echo newd="<$newd>";
if [[ $newd == "" ]]; then
echo "cd $* failed" 1>&2;
else
if [[ $oldd == $newd ]]; then
echo "cd $* - no change" 1>&2;
else
command cd "$@" 2> /dev/null 1>&2;
fi;
fi
  }

Running bash on Cygwin (taken from Cygwin):
  version:
GNU bash, version 3.2.15(13)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.
the redirection in the assignment of newd for "command cd" doesn't work
(when cd generates output). I have a CDPATH=.:/home/tbalinski; now when I
use my cd function to go from MiscDocs to Dev (both in /home/tbalinski) I
get:
  $ cd Dev
  oldd=
  newd=
  $
i.e. the newd variable was assigned both the output of cd (which should
have gone to /dev/null) and of the pwd that follows it, rather than just
the pwd. (I also tried "1>/dev/null 2>&1" for the redirects, same results).

Curiously, under the same conditions on a Red Hat Linux box:
  version:
GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
I get the behaviour I expected: only one line in newd:
  $ cd Dev
  oldd=
  newd=
  $

Either something strange is going on with the Cygwin compatibility layer
or there is a problem with the later bash. Or am I writing my command
wrongly?

Thanks,

Tony


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash