using -F fails using bash process substitution. bug?

[Zing Shishak]

The following fails to set svn:ignore using process substitution for the
file option:

$ svn ps svn:ignore -F <(echo -ne "ignorethis\n") .
property 'svn:ignore' set on '.'

The property is created but it's empty. Is this something that's not
expected to work? I seem to remember doing this in the past and having
it work.

[Philip Martin]

Post by Zing Shishak
The following fails to set svn:ignore using process substitution for the
$ svn ps svn:ignore -F <(echo -ne "ignorethis\n") .
property 'svn:ignore' set on '.'
The property is created but it's empty. Is this something that's not
expected to work? I seem to remember doing this in the past and having
it work.

The workaround is to use:

echo -ne "ignorethis\n" | svn ps svn:ignore -F - .

It's possible it did work in the past and in other places that construct
does work, e.g.

svnmucc -mm put <(echo foo) URL

Subversion has multiple ways to read a file and when reading from a pipe
(and that shell command constructs a pipe) the code that uses stat() to
get the filesize doesn't work because the pipe filesize is zero. There
is other code that doesn't use stat() and reads in block until EOF, and
that works for pipes. We might be able to fix the code that uses stat()
by having it check for EOF as well.

[Daniel Shahaf]

Post by Philip Martin
It's possible it did work in the past and in other places that construct
does work, e.g.
svnmucc -mm put <(echo foo) URL
Subversion has multiple ways to read a file and when reading from a pipe
(and that shell command constructs a pipe)

Some shells support a =(...) construct, which is like <(...) except it
expands not to a pipe but to an ordinary file, which can be seek()ed,
stat()ed, etc., so this problem wouldn't arise.

Post by Philip Martin
the code that uses stat() to get the filesize doesn't work because the
pipe filesize is zero. There is other code that doesn't use stat() and
reads in block until EOF, and that works for pipes. We might be able
to fix the code that uses stat() by having it check for EOF as well.

Cheers,

Daniel

[Daniel Shahaf]

Post by Philip Martin

Post by Zing Shishak
The following fails to set svn:ignore using process substitution for the
$ svn ps svn:ignore -F <(echo -ne "ignorethis\n") .
property 'svn:ignore' set on '.'
The property is created but it's empty. Is this something that's not
expected to work? I seem to remember doing this in the past and having
it work.

echo -ne "ignorethis\n" | svn ps svn:ignore -F - .

By the way, an even simpler workaround in this case is

svn ps svn:ignore -m $'ignorethis\n' ./

[Philip Martin]

Post by Daniel Shahaf

Post by Philip Martin
echo -ne "ignorethis\n" | svn ps svn:ignore -F - .

By the way, an even simpler workaround in this case is
svn ps svn:ignore -m $'ignorethis\n' ./

No. In this case -F specifies the property value, not the log message.

Something like this may work:

svn ps svn:ignore $(echo -ne "ignorethis\n") .

but quoting multiple line values can be tricky.

[Daniel Shahaf]

Post by Philip Martin

Post by Daniel Shahaf

Post by Philip Martin
echo -ne "ignorethis\n" | svn ps svn:ignore -F - .

By the way, an even simpler workaround in this case is
svn ps svn:ignore -m $'ignorethis\n' ./

No. In this case -F specifies the property value, not the log message.

Ah, my bad. In that case, just drop the -m:

svn ps svn:ignore $'line1\nline2\nline3\n' ./

This also shows one way to propset a multiline value.

Post by Philip Martin
svn ps svn:ignore $(echo -ne "ignorethis\n") .
but quoting multiple line values can be tricky.

This should work:

svn ps svn:ignore "$(printf '%s\n' 'line1' 'line2' 'line3' ...)"

(up to trailing newlines)

Cheers,

Daniel

[Zing Shishak]

Ok, thanks for the explanation. I can use the workaround.

[Daniel Shahaf]

Post by Philip Martin
We might be able to fix the code that uses stat()
by having it check for EOF as well.

I see you've now done this in r1836306. Any reason not to backport
that? (Feel free to add my +1)

[Philip Martin]

Post by Daniel Shahaf
I see you've now done this in r1836306. Any reason not to backport
that? (Feel free to add my +1)

Nominated for 1.10.