Category: Tech

Using if:set, unless:set etc. to execute a task conditionally in Ant

I’m not sure anyone except me is still struggling on with using Ant, but just in case, here is a nice thing.

In Ant 1.9.1 they added a useful feature: instead of needing to use the <if> tag and similar from ant-contrib, you can conditionally execute “any” task.

(In fact, this appears to mean “any task except a macrodef” – see my post Using if:set, unless:set etc. with macrodefs in Ant.)

You need to add these namespaces at the top of your project:

<project
     xmlns:if="ant:if"
     xmlns:unless="ant:unless"
>

and then make any task conditional by adding one of these attributes:

if:set
if:true
if:blank
unless:set
unless:true
unless:blank

if:set and unless:set take a property name and run the task if it is set at all (or unless it is set at all).

<mytask if:set="property.name" other_attrs="" .../>

Where mytask is the name of any ordinary Ant task like echo, jar etc.

(Note there is no ${} around the property name for if:set.)

if:true and unless:true take a value and run the task if it is true (or unless it is true), so they need to be used like this:

<mytask if:true="${property}" other_attrs="" .../>

(Note the ${} here, but not above.)

Similarly, if:blank and unless:blank take a value and run the task if it is blank (or unless it is blank), e.g.:

<mytask if:blank="${property}" other_attrs="" .../>

NOTE: The example in the documentation is wrong (at this time, 2013-09-13) – it uses the property name, but this does not work – you must surround it with ${} to get its value.

The properties can be specified in your build file as normal, or supplied on the command line to ant with -Dproperty.name=value.

Here’s an example of using set:

build.xml:

<project
    xmlns:if="ant:if"
    xmlns:unless="ant:unless"
    default="build"
>

    <property name="setinxml" value="true"/>

    <target name="build">
        <echo if:set="setinxml"     message="if:set=setinxml"/>
        <echo unless:set="setinxml" message="unless:set=setinxml"/>
        <echo if:set="notset"       message="if:set=notset"/>
        <echo unless:set="notset"   message="unless:set=notset"/>
        <echo if:set="setincmd"     message="if:set=setincmd"/>
        <echo unless:set="setincmd" message="unless:set=setincmd"/>
    </target>

</project>

And here’s the output:

$ ant -version
Apache Ant(TM) version 1.9.2 compiled on July 8 2013
$ ant -Dsetincmd=true
Buildfile: build.xml

build:
     [echo] if:set=setinxml
     [echo] unless:set=notset
     [echo] if:set=setincmd

BUILD SUCCESSFUL
Total time: 0 seconds

The documentation for this, such as it is, is here: If And Unless.

Behaviour of Java String.split() when some answers are the empty string

Can you guess the output of this program?

class SplitTest
{
    static void split( String s )
    {
        System.out.println( s.split( ";" ).length );
    }

    public static void main( String[] args )
    {
        split("");
        split(";");
        split("x;");
        split(";y");
    }
}

Here it is:

$ javac SplitTest.java && java SplitTest
1
0
1
2

Wow. Docs: String.split.

Side note: It’s not easy to fit Java examples into tweets.

Checking the case of a filename on Windows

Windows generally uses a case-insensitive but not case-preserving file system.

When writing some code that is intended to be used on Linux as well as Windows, I wanted it to fail on Windows in the same cases that it would fail on Linux, and this meant detecting when the case of a filename differed from its canonical case on the file system.

I want to ask “is this file name correct in terms of case?”

I was working in Java, but I think this issue would be similar in other languages: it’s difficult to ask for the canonical case version of a file name when we currently have a filename with abitrary case.

The only solution I came up with was to list the contents of the parent directory and check whether my arbitrary filename is listed with the correct case in the results:

// CaseCheck.java

import java.util.Arrays;
import java.io.File;
import java.io.IOException;

class CaseCheck
{
    private static File parentFile( File f )
    {
        File ret = f.getParentFile();
        if ( ret == null )
        {
            ret = new File( "." );
        }
        return ret;
    }

    private static boolean existsAndCaseCorrect( String fileName )
    {
        File f = new File( fileName );
        return Arrays.asList( parentFile( f ).list() ).contains( f.getName() );
    }

    public static void main( String[] args ) throws IOException
    {
        System.out.println( existsAndCaseCorrect( args[0] ) );
    }
}

Checking it on its own source file:

javac CaseCheck.java && java CaseCheck cASEcheck.java
false

javac CaseCheck.java && java CaseCheck CaseCheck.java
true

It seems to work.

Note that this also returns false if the file doesn’t exist, and will throw an error if the file name specifies a parent directory that doesn’t exist.

Passing several values through a pipe in bash

I have been fiddling with some git-related shell scripts, and decided to try and follow the same approach as git in their structure. This means using the Unix system where each piece of functionality is a separate script (or executable) that communicates by using command-line arguments, reading from the standard input stream, and writing output to the standard output stream.

This allows each piece of functionality to be written in any programming or scripting language. In git’s case this has allowed initial versions to be written in bash or perl and later optimised versions (sometimes written in C) to be dropped in, piece by piece. It’s an incredibily flexible way of working and can also be very efficient.

Most of my prototyping has been in bash, and I’ve found sometimes I need to write out multiple values from a script and collect them as input in another script.

Writing the output is simple:

#!/bin/bash

# outputter.bash

# Imagine A, B and C have been created by some complex process:
A="foo bar"
B="  bar"
C="baz   "

# At the end of our script we simply write them out on separate lines in a known order
echo "${A}"
echo "${B}"
echo "${C}"

But reading them in somewhere else gave me some trouble until I learned this recipe:

#!/bin/bash

# inputter.bash

# Read in the values one per line:
IFS=$'\n' read A
IFS=$'\n' read B
IFS=$'\n' read C

# Now we can use them.
echo "A='${A}'"
echo "B='${B}'"
echo "C='${C}'"

And now the values transfer succesfully, preserving whitespace:

$ ./outputter.bash | ./inputter.bash 
A='foo bar'
B='  bar'
C='baz   '

The recipe uses bash’s built-in read command to populate the variables, but sets the IFS variable (Internal Field Separator) to a newline, meaning all the whitespace in the line is treated as part of the value to be read. The $'\n' syntax is a literal newline.