On Mon, Sep 21, 2015 at 7:03 PM, Lars Schneider
<larsxschnei...@gmail.com> wrote:
> On 21 Sep 2015, at 20:09, Junio C Hamano <gits...@pobox.com> wrote:
>> larsxschnei...@gmail.com writes:
>>> +test_expect_success 'init depot with UTF-16 encoded file and artificially
>>> remove BOM' '
>>> + (
>>> + cd "db" &&
>>> + p4d -jc &&
>>> + # P4D automatically adds a BOM. Remove it here to make the
>>> file invalid.
>>> + sed -e "$ d" depot/file1,v >depot/file1,v.new &&
>>
>> Do you need the space between the address $ (i.e. the last line) and
>> operation 'd' (i.e. delete it)? I am asking because that looks very
>> unusual at least in our codebase.
>
> Well, I am no “sed” pro. I have to admit that I found this snippet
> on the Internet and it just worked. If I remove the space then it
> does not work. I was not yet able to figure out why… anyone an idea?
Yes, it's because $d is a variable reference, even within double
quotes. Typically, one uses single quotes around the sed argument to
suppress this sort of undesired behavior. Since the entire test body
is already within single quotes, however, changing the sed argument to
use single quotes, rather than double, will require escaping them:
sed -e \'$d\' depot/file...
Aside: You could also drop the unnecessary quotes from the 'cd' argument.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
