I'm sorry to be so blunt about it, but redefining RTC's properties with my own properties that reference the RTC ones is a ridiculous workaround.

You could also just as easily make life simple for users of the command-line build definition by exporting the env vars with all caps and with underscore ('_') delimiters instead of dots ('.'); that would take care of both of my problems. You can even leave the exports as they are now and do what I'm suggesting as an addition instead of a replacement.

My first problem is that the "Add build properties to native environment" setting is useless on Unix, as all of the injected environment variables have the "." character in them; bash can't deference env. vars with "." in the name (or at least I haven't found a way to do this)

In regards to point 1:

Just to clarify a point for other readers....You mentioned "as all of the injected environment variables have the '.' in them"... however for the most part this is only true for the built in build properties such as "team.scm.workspaceUUID" or "team.scm.fetchDestination" etc.. You can add build properties in the "Properties" tab of either the Build Engine, Build Definition, or in the "Request Build" dialog which do 'not' have a "." in them. One original intent for build properties was to allow them to be passed as properties into an Ant task (which works fine with a "." in the name). In order to reduce possible conflicts we thought it would be a good idea to append a prefix corresponding roughly to the particular configuration element (tab) which contributes them (ex "team.scm" for the "Jazz Source Control" tab). The ability to add build properties as environment variables came much later unfortunatly. If we were to change the names of all our build properties however, I would assume it would break everyone's build who is using RTC and JBE (interally and customers). One alternative would be to make custom properties (in the "Properties" tab) which has a different name but the same value... for example:
name: FETCH_DESTINATION
value: ${team.scm.fetchDestination}

Now you can use FETCH_DESTINATION in your script

My second problem is with case differences between Windows & Unix; on Unix the injected env. vars are mixed-case & track with the names used on the build definition pages. On Windows they are in all caps. I'm trying to write a cross-platform script (using cygwin on Windows) and this casing difference is making things very hard

In regards to point 2:

Unfortunatly the problem with case sensitivity of environment variables between Windows and *nix has been around for a while.

The issue is that in *nix, environment variables are case sensitive such that "myVar" is different than "MYVAR", whereas in Windows environment variables are actually case insensitive, and so "myVar" is no different than "MYVAR". One consequence is that you cannot convert a set of *nix environment variables into a set of Windows environment variables. The convention in Windows is to uppercase all environment variables to avoid confusion.

The best thing to do is write an equivalent procedure/method in your script that is used to get the value of a given environment variable. If the operating system is windows (determined in the script), capitalize the environment variable and make the request, otherwise keep the same case.
Even doing this it is impossible to have a script work exactly the same in all operating systems. If for example you create build properties called "myVar" and "MYVAR", and referenced each one as "expected" in the script on a *nix system, then everything would work fine, however as soon as you go to Windows everything would break because of Windows case insensitivity. This is obviously avoided by having unique names.


There are not that many built in build properties, so you could easy define all your own properties (in the "Properties" tab) in the same way I showed above in point 1. If you use uppercase then it will work in both Windows and *nix and it gets rid of the "." problem.

I'm sorry to be so blunt about it, but redefining RTC's properties with my own properties that reference the RTC ones is a ridiculous workaround.

Yes, but those are both workarounds that any user can do 'today' without having to wait till the next release of RTC which include any changes to our command-line build definition.

You did ask 'Any other ideas?'....

Fair enough; you're right, we can do that today to hold us over until the next release.

That solution may work in your current situation, but would it work for everyone? If some other customer wants a build property called "myVar" and another called "MYVAR", from a build property point of view those are completely valid. Now if the user has a script that he only runs in Unix, he might expect that he could reference "myVar" and "MYVAR" as separate environment variables, if we force them to be capitalized before we add them as environment variables then he cannot do that. I'm not saying this is not a possibility, but we have to first consider all options and who it affects. If there are any changes to be done, all of this will have to be expressed in a work item.

I'm not asking that you capitalize ALL build properties, just the ones that you inject that I have no control over (e.g. team.scm.*, buildResultUUID, buildDefinitionId). And again, I'm not even saying that you can't continue to do what you're doing: I'm just asking that you ALSO inject the "special RTC" variables in such a way that they are usable from a standard shell script.