mv in -current behaves strange in script

Ramurd · 08-06-2009, 04:27 AM

Last night I made a slack box as a Virtual Machine and updated it to -current. When I ran my build script, I noticed very strange behavior in the "mv" command. I will list the script code here, along with the workaround in it. Still I am confused and hope someone from Slack can help shed a light on the behavior. The buildscript is for MLT btw, in red the workaround;

Code:

#!/bin/sh

#
# Global variables
#

CURDIR=`pwd`
BUILDDIR="${CURDIR}/mlt"
TARGETDIR="${CURDIR}/target"
INSTALLDIR="${TARGETDIR}/usr/"
ARCH=${ARCH:-i686}
BUILD=${BUILD:-1}
TAG=${TAG:-_MDG}
PRGNAME=mlt
VERSION="0.4.4"

main()
{
	makedirs
	uncompress
	build
	make_pkg
	cleanup
}

download()
{
	echo "Starting download..."
	wget http://downloads.sourceforge.net/project/mlt/mlt/${VERSION}/mlt-${VERSION}.tar.gz?use_mirror=ovh
	echo "Download complete"
}

uncompress()
{
	if [ -e ${PRGNAME}-${VERSION}.tar.gz ]
	then
		echo "Uncompressing..."
		tar zxf ${PRGNAME}-${VERSION}.tar.gz
		if [ -d ${PRGNAME}-${VERSION} ]
		then
			# when downloaded from stable branch
			# the source directory gets a version number
			# it gets stripped here
			mv ${PRGNAME}-${VERSION} ${PRGNAME}
			if [ -d ${PRGNAME}/${PRGNAME}-${VERSION} ]
			then
				# Something strange happens in Slackware-current
				# where there is a directory placed _between_
				# the current directory and the source directory
				cd ${PRGNAME}
				mv ${PRGNAME}-${VERSION}/* ./
				cd ..
			fi
		fi
	else
		download
	fi
}

makedirs()
{
	echo "Creating dirs..."
	mkdir -p ${SRCDIR} ${BUILDDIR} ${TARGETDIR}
}

build()
{
	cd ${BUILDDIR}
	./configure --prefix=${INSTALLDIR} --enable-gpl --qimage-libdir=/usr/lib/ --qimage-includedir=/usr/include/qt4 --avformat-swscale
	if [ $? -eq 0 ]
	then
		make
		make install
	fi
}

cleanup()
{
	echo "Cleaning up"
	cd ${CURDIR}
	rm -rf ${TARGETDIR} ${BUILDDIR} ${PRGNAME}
}

make_pkg()
{
	mkdir -p ${TARGETDIR}/usr/doc/${PRGNAME}-${VERSION}

	cp -a AUTHORS COPYING INSTALL README ${TARGETDIR}/usr/doc/${PRGNAME}-${VERSION} 
	cat ${CURDIR}/${PRGNAME}.SlackBuild > ${TARGETDIR}/usr/doc/${PRGNAME}-${VERSION}/${PRGNAME}.SlackBuild
	find ${TARGETDIR}/usr/doc/$PRGNAM-$VERSION -type f -exec chmod 644 {} \;

	mkdir -p ${TARGETDIR}/install
	cat ${CURDIR}/slack-desc > ${TARGETDIR}/install/slack-desc

	cd ${TARGETDIR}
	/sbin/makepkg -l y -c n ${CURDIR}/${PRGNAME}-${VERSION}-${BUILD}-${ARCH}${TAG}.tgz

}

main

When I run these commands manually, as a test

Code:

mv <dir> <new name of the dir>

the predictable happens, <dir> gets renamed to <new name of the dir>. In the script I got <new name of the dir>/<dir>; <dir> got moved into a newly created directory.

In 12.2 this behavior did not happen, in -current it does. Anyone with any clues?

Secondly, the manpage of makepkg nor makepkg -h tells how to make the packages in the new format; But that's something minor to me.

gnashley · 08-06-2009, 07:24 AM

Most likely a change because of upgrading to coreutils-7.4 from 6.12. coreutils has been gradually implementing newer POSIX standards for a long while and this may be due to that.

Ramurd · 08-06-2009, 07:30 AM

I could understand that if in script and on prompt behaved similar, but overall a good pointer! What I'm wondering is how this may affect other programs, since mv has a tendency to be used often, mostly in scripts. All those scripts would behave different than expected based on previous behavior.

rg3 · 08-06-2009, 09:53 AM

I suspect the problem is not in mv. mv behaves that way when the destination directory exists. In other words, mv old_dir new_dir renames the directory, unless new_dir is already a directory. In that case it moves old_dir into new_dir. You should check the directory does not exist before running mv.

Ramurd · 08-06-2009, 10:36 AM

I know that is the normal behavior, as this is defined in the standard; Now it wasn't so early last night when I ran this, but still pretty certain the directory does not exist prior to running "mv"; Now there is a (small) chance this directory comes to exist during the script; I'll have a look on that.

I ran this script in a new, empty directory; heck, I even kicked the lady out of it ;-) When I run this script again (tonight) I will monitor very closely what directories come to exist and either come back groveling saying I was at fault or still with this big questionmark above my head.

Ramurd · 08-06-2009, 02:54 PM

I have to disappoint here, I need another day or so; getting the next kdenlive package to compile at all took the greater part of the day, and that has priority for me. Will get back on this soon.

rworkman · 08-06-2009, 03:24 PM

Run the script with the -x flag and paste the relevant bits here.

Ramurd · 08-07-2009, 01:21 AM

ouch, I have to grovel humbly here...

When running with -x I noticed what happens in makedirs, one of the dirs made is ${BUILDDIR}; which happens to be "<path>/mlt", hence mv behaving as it should according to the standards. Still strange I made this beginners mistake and got away with it in 12.2;

Code:

++ pwd
+ CURDIR=/slackbuilds/mlt
+ BUILDDIR=/slackbuilds/mlt/mlt
+ TARGETDIR=/slackbuilds/mlt/target
+ INSTALLDIR=/slackbuilds/mlt/target/usr/
+ ARCH=i686
+ BUILD=1
+ TAG=_MDG
+ PRGNAME=mlt
+ VERSION=0.4.4
+ main
+ makedirs
+ echo 'Creating dirs...'
Creating dirs...
+ mkdir -p /slackbuilds/mlt/mlt /slackbuilds/mlt/target

rworkman · 08-07-2009, 08:09 AM

Quote:

Originally Posted by Ramurd

ouch, I have to grovel humbly here...

When running with -x I noticed what happens in makedirs, one of the dirs made is ${BUILDDIR}; which happens to be "<path>/mlt", hence mv behaving as it should according to the standards.

Very good - that's *exactly* what I expected to happen (that you would catch the mistake when looking at the -x output). :-)