Bug 402597

Created attachment 223627 [details]
zypper.log.gz

It is caused by having $CDPATH set (mine is 'CDPATH=.:/media:/mnt:/usr/share:/usr:/home'). The solv file is generated by redirecting output of the repo2solv.sh script and the script apparently does cd somewhere, which gets written at the beginning of the file (specifically, the path is e.g. /var/cache/zypp/raw/repo-oss/suse/setup/descr). I suggest 'unset CDPATH' at the beginning of repo2solv.sh (or beating hard whoever invented this cd+CDPATH misfeature).

*** Bug 402811 has been marked as a duplicate of this bug. ***

I happen to find Bash's CDPATH function quite useful, Lubos.  The bug here lies with repo2solv.sh, not Bash.

(Maybe, but the shell shouldn't print the cdpath to stdout if it's not in interactive mode.)

Looks like the 'unset CDPATH' workaround is implemented in satsolver. 

@Werner: IMO comment #5 is valid. 

It's fixed in svn, but we still need to submit a package plus make a maintenance update.

released

I'll expand on comment #5: bash shouldn't EVER print the directory to stdout, even in interactive mode.  It should go to stderr.  (And in non-interactive mode, as Michael points out, it should be silent.  Actually, I think that the correct behavior might be to ignore CDPATH in non-interactive mode; doing otherwise is a potential security hole.)

I couldn't find a bash bug open on this issue.  Perhaps somebody should open one?

To be noted: if you think this is a bash bug please report it upstream.
I'll not change common behaviour of the bash.  There is no point in the
current manual page which states that CDPATH is for interactive usage
only.  Beside this normaly CDPATH is empty.

Oh, fine, Werner.  Kick me in the butt and make me do what I should have done in the first place. :-D

I've reported it as a bash bug.

;) 
Maybe there are some more variables which are normaly used in
interactive mode but also available in script mode.  The question
rises how many scripts are out there relying on such variables
like CDPATH and others:

     #!/bin/bash 
     CDPATH=/tmp
     tmp=$(mktemp -d ${CDPATH}/${0##*/}.XXXXXX) || exit 1
     wrk=${tmp##*/}
     cd $wrk

Good point.  I've taken the liberty of filing a second bash bug report with your comments included, and basically saying that the bash developers need to audit bash.  My suggestion to them is that bash should null out all such variables at the top, and then let scripts set them if they choose.

Can you please provide links to the bash bug reports?  (I'm assuming they use some sort of online bug tracker rather than a mailing list.)

Bash's bug-reporting system is a script named "bashbug", which sends mail to their list.  I suppose they have an online tracker but I don't know where it is.

They've responded (by e-mail) to my reports.  The first response says, in essence, "That's the way the POSIX standard says CDPATH should behave."  The second says, in essence, "all variables are documented and it's the script-writers problem to deal with it."  He also pointed out that modifying bash to start unsetting dangerous variables is risky from a backwards-compatibility standpoint (which I think is a fair point).  Finally, he mentioned that the CDPATH issue has been reported multiple times.  I'd take that letter comment as a sign of a big design error, but that's going to be a hard sell.

I'm going to reply, pointing out that the POSIX standard is (a) ambiguous about whether CDPATH needs to be reported for non-interactive shells, and (b) wrong for asking it to be reported to stdout.  But I doubt I'll win the argument.

So I think we're stuck with it.  Something I came across pointed out that you can always write "cd ./foo" instead of "cd foo", but that's hardly more convenient that simply unsetting CDPATH.

(Reassigned to werner as the update is released and this is about bash...)

As already told (see I comment #11)  will not change the common behaviour
of the bash. This should happen upstream only.

Ok, closing (as a fixed libzypp is already avaiable, see #9)