Simple Question on Executing Command in the Right Working Directory

[Josh Padnick]

This seems like such a simple issue with an obvious fix, but I must be missing something. I'm executing a Command task whose job in life is to rename a file. Here's how I've defined it:

• Executable = /bin/mv
• Argument = *.tgz ${bamboo.appName}.tgz
• Environment Variables = <blank>
• Working Subdirectory = target/universal

Now here's my file system:

/WORKING_DIRECTORY

-- target

-- -- universal

-- -- -- myappname.tgz

But when I execute this, I get the following errors:

simple 14-Mar-2014 03:46:05    Starting task 'Rename artifact' of type 'com.atlassian.bamboo.plugins.scripttask:task.builder.command'	
command 14-Mar-2014 03:46:05	Beginning to execute external process for build 'Aragorn - Test Plan - Download Commit and Build #17 (ARA-TEST-DS-17)'\n ... running command line: \n/bin/mv *.tgz aragorn.tgz\n ... in: /var/lib/bamboo/bamboo-home/xml-data/build-dir/ARA-TEST-DS/target/universal\n ... using extra environment variables: \nbamboo_appName=aragorn\n 
error 14-Mar-2014 03:46:05	/bin/mv: cannot stat `*.tgz': No such file or directory
simple 14-Mar-2014 03:46:05	Failing task since return code of [/bin/mv *.tgz aragorn.tgz] was 1 while expected 0

The "cannot stat" error basically means the "mv" command can't find the file in the current directory.

But when I SSH into the server and manually go to /var/lib/bamboo/bamboo-home/xml-data/build-dir/ARA-TEST-DS/target/universal and then manually run "/bin/mv *.tgz aragorn.tgz" it works just fine.

Any ideas what's going on here?

[Josh Padnick · Accepted solution]

I was able to resolve the issue by removing the * from the mv command. It seems by passing in the exact filename, it works just fine. I would consider this a Bamboo bug of some kind since I proved to myself that I was in fact in the directory I thought. It's just that Bamboo dislikes executing "*".

Thank you for the responses!

[Nick Hilton]

I've found this thread by googling atlassian bamboo tar command using wildcards, I've found a HACK / workround.

Use the bash executable and included back tick expressions.  For example, here my tar extract command using /bin/bash task:

-c 'tar xf `ls *.tar.bz2`'

When BASH executes the snippet above, the back tick expression is executed and the wildcard is interpreted properly.

Hope this helps someone.

[Nick Hilton]

I've found this thread by googling  atlassian bamboo tar command using wildcards, I've found a hack or workround.

Use the bash executable and use back tick expressions for wildcards.  For example, here is my tar command using the /bin/bash task executable:

-c 'tar xf `ls *.tar.bz2`'

When BASH executes the snippet above, the back tick expression is executed and the wildcard is interpreted properly.

Hope this helps someone.

[Config Manager]

It is a grave, but that's just the error report from the mv command being stupid.

Type mv fred bill in almost any bash/sh window and you'll get a similar result.

[Jason Monsorno]

`*.tgz'

The lefthand side is using a grave accent and the righthand side is using an apostrophe. Is that an display side effect of the log of is it a typo in the command?

[Config Manager]

The command /bin/mv *.tgz aragorn.tgz will only work if

- aragorn.tgz is an existing local directory (probably not what you meant)
or
- there is only one file with .tgz extension in the directory - i.e. aragorn.tgz does not already exist and there is not more than 1 other.

If you are using the wildcard to pick up multiple files then it won't work. You can't "move" several files into a single destination file, although you can move them in to one destination directory. If you only have one file, I would explicitly name it. Check out mv help if you are unsure how it works. EG at http://ss64.com/bash/mv.html<br< a="">>
I can't explain why it appears to work manually but not in Bamboo, but it's probably due to you not running the command manually exactly like Bamboo does (we all do that once or twice when setting up this sort of thing!).