Make script cross-platform.

Make script cross-platform.

BUG=none
TEST=try script on both Mac and Linux on Mac build output.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=69274

[Scott Byer, 2010-12-14 00:30:09]

The typical portability trick doesn't work when the executable needs an
argument, as is the case here, so thus the not-as-pretty here document.

Now the script can be used with Mac command line builds as well.

[evanm, 2010-12-14 00:33:57]

On 2010/12/14 00:30:09, Scott Byer wrote:
> The typical portability trick doesn't work when the executable needs an
> argument, as is the case here

How come?

[Scott Byer, 2010-12-14 00:49:41]

On Linux, everything after the first argument gets passed as a single word to
that executable, thus in this case the typical

#!/usr/bin/env sed -f

causes a complaint because "sed -f" doesn't exist.


On 2010/12/14 00:33:57, evanm wrote:
> On 2010/12/14 00:30:09, Scott Byer wrote:
> > The typical portability trick doesn't work when the executable needs an
> > argument, as is the case here
> 
> How come?

[Evan Martin, 2010-12-14 00:54:21]

On 2010/12/14 00:49:41, Scott Byer wrote:
> On Linux, everything after the first argument gets passed as a single word to
> that executable, thus in this case the typical
> 
> #!/usr/bin/env sed -f

Oh, I see, and you want to use env to run sed to work on Mac?

Hm, ok.  One more question: rather than a temp file, why not use an inline here
document like

sed -f - <<EOT
content here
EOT

?

[Scott Byer, 2010-12-14 01:01:28]

Can't work; stdin is where the thing to be edited is coming from, so can't be
used for the commands.

If you're squeemish about leaving the temp file hanging around, I can always not
exec sed and kill the temp file afterwards.

On 2010/12/14 00:54:21, Evan Martin wrote:
> On 2010/12/14 00:49:41, Scott Byer wrote:
> > On Linux, everything after the first argument gets passed as a single word
to
> > that executable, thus in this case the typical
> > 
> > #!/usr/bin/env sed -f
> 
> Oh, I see, and you want to use env to run sed to work on Mac?
> 
> Hm, ok.  One more question: rather than a temp file, why not use an inline
here
> document like
> 
> sed -f - <<EOT
> content here
> EOT
> 
> ?

[evanm, 2010-12-14 01:04:07]

On 2010/12/14 01:01:28, Scott Byer wrote:
> If you're squeemish about leaving the temp file hanging around, I can always
not
> exec sed and kill the temp file afterwards.

It does make me feel funny.  Third option: require the caller to call this with
"sed" and just remove the +x bit.
Fourth option: rewrite in Python, which is needed on Windows anyway.  :\
Fifth option: figure out why Emacs isn't fast enough to do this.  :(

[scottbyer, 2010-12-14 01:14:24]

Mmm.  Python's probably the right answer, though the here document should
work fine for Cygwin (haven't tried it yet).  Something to do for tomorrow
morning...

Emacs is optimized around having a small window into lots of text for
quick(ish) modification, not around global modifications on large buffers -
that's what sed is for ;-).

On Mon, Dec 13, 2010 at 5:04 PM, <evanm@google.com> wrote:

> On 2010/12/14 01:01:28, Scott Byer wrote:
>
>> If you're squeemish about leaving the temp file hanging around, I can
>> always
>>
> not
>
>> exec sed and kill the temp file afterwards.
>>
>
> It does make me feel funny.  Third option: require the caller to call this
> with
> "sed" and just remove the +x bit.
> Fourth option: rewrite in Python, which is needed on Windows anyway.  :\
> Fifth option: figure out why Emacs isn't fast enough to do this.  :(
>
>
> http://codereview.chromium.org/5746007/
>

[Scott Byer, 2010-12-14 21:55:28]

I thought about it a bunch more and sed really is the right tool here. 
Splitting out the shell wrapper gets rid of the temp file problem and still
allows for direct sed -f usage where appropriate.  I've tested this latest set
on all three platforms.  If it turns out there really are a lot of people
running Emacs on Windows without Cygwin, well, then we could reconsider Python I
suppose.

-Scott

On 2010/12/14 01:14:24, scottbyer wrote:
> Mmm.  Python's probably the right answer, though the here document should
> work fine for Cygwin (haven't tried it yet).  Something to do for tomorrow
> morning...
> 
> Emacs is optimized around having a small window into lots of text for
> quick(ish) modification, not around global modifications on large buffers -
> that's what sed is for ;-).
> 
> On Mon, Dec 13, 2010 at 5:04 PM, <mailto:evanm@google.com> wrote:
> 
> > On 2010/12/14 01:01:28, Scott Byer wrote:
> >
> >> If you're squeemish about leaving the temp file hanging around, I can
> >> always
> >>
> > not
> >
> >> exec sed and kill the temp file afterwards.
> >>
> >
> > It does make me feel funny.  Third option: require the caller to call this
> > with
> > "sed" and just remove the +x bit.
> > Fourth option: rewrite in Python, which is needed on Windows anyway.  :\
> > Fifth option: figure out why Emacs isn't fast enough to do this.  :(
> >
> >
> > http://codereview.chromium.org/5746007/
> >

[Evan Martin, 2010-12-14 22:01:53]

http://codereview.chromium.org/5746007/diff/9001/build/sanitize-mac-build-log.sh
File build/sanitize-mac-build-log.sh (right):

http://codereview.chromium.org/5746007/diff/9001/build/sanitize-mac-build-log...
build/sanitize-mac-build-log.sh:4: sed -f ${dir}/${root%\.*}.sed
I think elsewhere we just use `dirname $0`.  What do you think?

[Scott Byer, 2010-12-14 22:17:25]

http://codereview.chromium.org/5746007/diff/9001/build/sanitize-mac-build-log.sh
File build/sanitize-mac-build-log.sh (right):

http://codereview.chromium.org/5746007/diff/9001/build/sanitize-mac-build-log...
build/sanitize-mac-build-log.sh:4: sed -f ${dir}/${root%\.*}.sed

I think that my shell-fu needs modernizing.  Done.

On 2010/12/14 22:01:53, Evan Martin wrote:
> I think elsewhere we just use `dirname $0`.  What do you think?

[Evan Martin, 2010-12-14 22:18:17]

LGTM, sorry for the long review