Support line continuation characters on Unix

[jonpryor]

In some recent work I've had need to execute an external program, so the <Exec/> task comes in handy:

<Exec Command="configure" />

The problem, though, is that the command I really need to execute is long -- resulting in a line which is nearly 596 characters long:

<Exec
       Command="configure LD=&quote;...&quote; ... # plus hundreds more characters..."
/>

I want shorter lines, both to make it easier to read, and to simplify version control review and validation (long lines make for terrible diffs).

There are (at least?) two ways to make for shorter lines:

1. Use more variables

   <PropertyGroup>
     <Ld>LD=&quot;@(Runtimes->'%(Ld)')&quot;</Ld>
     <!-- ... -->
   </PropertyGroup>
   <Exec
       Command="configure $(Ld) ..."
   />
   

2. Use line continuations:

   <Exec
       Command="configure ^
         LD=&quot;...&quot; ^
         ..."
   />
   

Truth be told, I tried (1) first, but that doesn't work with xbuild on OS X (doh!).

So I try the Unix variant on (2):

<Exec
    Command="configure \
      LD=&quot;...&quot; \
      ..."
/>

...which promptly fails because \ is replaced with / at all instances in both xbuild and msbuild (which is why I'm bringing it up here... ;-).

What would be useful is some way of using line-continuation characters in a portable fashion. I can think of two ways to support this:

1. On Unix, replace ^<newline> with \<newline>. This would allow us to use the Windows line-continuation character of ^ in a portable fashion.

   The problem with this is if there are any shells or commands for which a trailing ^ is appropriate, though I can't think of any programs which use ^ in this manner offhand.

2. Fix the s#\#/#g replacement that MSBuild performs so that \<newline> can be used within the //Exec/@Command attribute. Then, we could use Conditional to have one command for Windows and a different command for Unix:

   <Exec
       Condition="' $(OS' == 'Windows_NT' "
       Command="this is a ^
         very long command"
   />
   <Exec
       Condition="' $(OS' != 'Windows_NT' "
       Command="this is a \
         very long command"
   />
   

[rainersigwald]

This isn't the only pain we've had from backslash-replacement (see also #422). At first glance I lean toward your option 1, but a relevant question is how often you get a really long command line that's identical cross-platform--if you usually have to substitute strings anyway, having a separate escape character seems ok.

Re: trailing ^: it's used in git revision specifications, but that's the only thing I can think of offhand.

[radical]

For issues like #422, I was thinking that an acceptable solution might be to use xml entity code (\ for \) and the slash fixup should be done before these codes are unescaped. That way the default behavior would be to convert the slashes (s,\,/,), but if the user needs a particular usage to not be converted, then they can use the xml entity code.

[radical]

I wonder if converting ^ to \ might be a slippery slope - start converting more and more things from cmd to sh style? It might be better to "force" the user to use separate Exec instances, per OS. If the line continuation character is the only issue, then they could put that in a property? And combined with my earlier comment, it should work for both ^ and \.

[jonpryor]

...and now that we've open-sourced things, I can link to the line in question.

It's 591 characters wide.

[rainersigwald]

@jonpryor It doesn't mean we shouldn't do this, but one pattern I've seen to work around this without line-continuations is something like this:

<PropertyGroup>
  <ConfigureCommand>path\to\executable first_argument</ConfigureCommand>
  <ConfigureCommand>$(ConfigureCommand) another_argument</ConfigureCommand>
  <ConfigureCommand>$(ConfigureCommand) yet_another_argument</ConfigureCommand>
  <ConfigureCommand>$(ConfigureCommand) still_another_argument</ConfigureCommand>
</PropertyGroup>

<Exec Command="$(ConfigureCommand)" />

With a bunch of successive appends, so that while the actual command itself is super long and unwieldy, its construction in MSBuild is a bit more constrained. This is similar to your initial workaround 1, so it might hit the same problem as xbuild, unfortunately.

(Seeing an example brought this to mind, thanks!)