cd "" foo bug?

cd "" foo bug?

[Dominik Vogt]

cd with two arguments works fine if the second argument is an
empty string, but not if the first argument is an empty string.
Shouldn't it try all possible positions for the "" instead of just
the first one?

 $ cd ~/gcc/build/gcc
 $ builtin cd build ""
 ~/gcc/gcc
 $ builtin cd "" build
 cd: no such file or directory: build/home/user/gcc/gcc

 $ zsh --version
 zsh 5.0.2 (s390x-ibm-linux-gnu)                                             

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: cd "" foo bug?

[Peter Stephenson]

On Mon, 11 Jan 2016 12:20:26 +0100
Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> cd with two arguments works fine if the second argument is an
> empty string, but not if the first argument is an empty string.
> Shouldn't it try all possible positions for the "" instead of just
> the first one?

That's not really compatible with how two-argument cd normally works.

% mkdir ~/tmp/foofoo ~/tmp/foobar
% cdpath=(~/tmp)
% cd ~/tmp/foofoo
% cd foo bar
cd: no such file or directory: /export/home/pws/tmp/barfoo

If it's going to try all possible source matches it should do it in this
case, too.  As it is, it always just tries the first match.

This sounds more like an extension for a function.  The (I) flag already
handles the special case of an empty string the way you want, so no
special cases within the function.

pws


# should handle options up here...

if (( $# == 2 )); then
  local src=$1 rep=$2 dir
  integer n=1
  while true; do
    dir=${(I:${n}:)PWD/$src/$rep}
    if [[ $dir = $PWD ]]; then
      print -r "$0: no replacements found: $PWD / \"$src\" / \"$rep\"" >&2
      return 1
    fi
    if [[ -d $dir ]]; then
      cd -- $dir
      return
    fi
    (( n++ ))
  done
else
  builtin cd "$@"
fi

Re: cd "" foo bug?

[Dominik Vogt]

On Mon, Jan 11, 2016 at 11:58:04AM +0000, Peter Stephenson wrote:
> On Mon, 11 Jan 2016 12:20:26 +0100
> # should handle options up here...
> 
> if (( $# == 2 )); then
>   local src=$1 rep=$2 dir
>   integer n=1
>   while true; do
>     dir=${(I:${n}:)PWD/$src/$rep}
>     if [[ $dir = $PWD ]]; then
>       print -r "$0: no replacements found: $PWD / \"$src\" / \"$rep\"" >&2
>       return 1
>     fi
>     if [[ -d $dir ]]; then

>       cd -- $dir

How is this supposed to work?  The manual does not mention "--":

  http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#Shell-Builtin-Commands

The shell silently accepts it but seems to completely ignore it:

  $ zsh --version
  zsh 5.0.2 (s390x-ibm-linux-gnu)

  $ mkdir /tmp/-1
  $ builtin cd /tmp
  # note: pushdminus and autopushd are on
  $ builtin cd -- -1
  ~
  $ pwd
  /home/<user>

But on the other hand it works with -- as the directory name:

  $ mkdir /tmp/--
  $ builtin cd /tmp
  $ builtin cd -- --
  $ pwd
  /tmp/--

As far as I can see there is no direct way to pass -<n>, +<n>, -q,
-s, -L or -P as a directory argument to the cd builtin.  -- is
undocumented but works like in many other Unix tools, but not when
used with one of the options above.  -- works fine with
two-argument cd calls.

>       return
>     fi
>     (( n++ ))
>   done
> else
>   builtin cd "$@"
> fi

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: cd "" foo bug?

[Peter Stephenson]

On Fri, 15 Jan 2016 10:45:26 +0100
Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> >       cd -- $dir
> 
> How is this supposed to work?  The manual does not mention "--":

You're correct that cd is funny with options, no doubt partly because of
-<NUM>, so you can forget the "--".  Yes, I think directories beginning
with "-" are intrinsically somewhat inconsistently handled in the
builtin (and presumably always have been).

pws

Re: cd "" foo bug?

[Dominik Vogt]

On Fri, Jan 15, 2016 at 10:41:14AM +0000, Peter Stephenson wrote:
> On Fri, 15 Jan 2016 10:45:26 +0100
> Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> > >       cd -- $dir
> > 
> > How is this supposed to work?  The manual does not mention "--":
> 
> You're correct that cd is funny with options, no doubt partly because of
> -<NUM>, so you can forget the "--".  Yes, I think directories beginning
> with "-" are intrinsically somewhat inconsistently handled in the
> builtin (and presumably always have been).

Any chance to at fix "--" so that

  cd -- -1
  cd -- +1
  cd -- -q

actually work?  Currently it's complicated to write a script that
correctly invokes cd with some path P:

  IF P is -<n> or +<n>
    cd "./$P"
  ELSE IF P matches -[qsLP]## (in the sense of extended globbing)
    cd "./$P"
  ELSE IF P is --
    cd -- --
  ELSE
    cd "$P"

With the suggested change you could simply do

  cd -- "$P"

in all cases.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: cd "" foo bug?

[Bart Schaefer]

On Jan 15, 12:29pm, Dominik Vogt wrote:
}
} Any chance to at fix "--" so that
} 
}   cd -- -1
}   cd -- +1
}   cd -- -q
} 
} actually work?

That last one DOES work.  The -- option will prevent anything that looks
like an option from being interpreted as an option.  The only special
case is with digits after the +/-.

Changing that is messy because of the way bin_cd() is structured -- a
new flag would have to be passed to cd_get_dest() to tell it not to use
the directory stack, among other things.