[R] Sweave: conflict between setwd and \SweaveOpts{prefix.string=}

[Matthieu Stigler]

> Have you tried specifying an absolute path in prefix.string instead of a
> relative one?
>
> HTH,
>
> Thierry 


Good point! This actually solves the problem, I just wanted to avoid 
this as I wanted to send it to someone else... so I just reordered the 
files and it works.

Solutions given by Duncan work also, nice!

I agree with you Duncan, it is not a big problem, and doesn't need at 
all priority, but mentioning it is maybe worth in the doc, especially if 
this could avoid someone to lose those two hours I lost with this

Thanks to all you both!

Duncan Murdoch a écrit :
> Matthieu Stigler wrote:
>> Hello
>>
>> I think there is a conflict between setwd() and 
>> \SweaveOpts{prefix.string=}. In the same document, those both command 
>> get Sweave confuse the files and directories. See:
>>
>> say my .Rnw document is in File1
>>
>> If one inserts some setwd() for another file:
>> -setwd(File2)
>>
>> then the command \SweaveOpts{prefix.string=graphics/Rplots} will 
>> search the "graphics" folder in File2 because of command setwd(File2) 
>> and not in File1 where the .Rnw file is and as is said in Sweave 
>> Manual A10.
>>
>> Hence Latex get really confused and does not work anymore: the 
>> command \includegraphics looks for folder "graphics" in the usual 
>> File1 but those can have been stored in File2.
>>
>> I tried to add some:
>> \usepackage{graphicx}
>> \graphicspath{{../File2/graphics/}}
>> but resulot was not so convincing
>>
>> Is there anyway to avoid this? Thanks!
>>   
>
> You could use a fully qualified prefix, so it doesn't matter what the 
> current directory is when you save a plot.
>
> Or you could avoid setwd().
>
> Or you could change back to the original directory before drawing a plot.
>
> It would probably make sense for Sweave to do the last of these 
> internally:  it is mixing up characteristics of the session it's 
> running in with characteristics of the session it is running.  
> However, this is a pretty strange case, and I'm not sure fixing it 
> will be a high priority.
>
> Duncan Murdoch