[posted and mailed] Angus Leeming <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> > You say that, if you run convertDefault.sh 'by hand', it works > perfectly? Yes > Could you try again with this new version, dumping output > to a LyX temp directory. > > In fact, since file names like C:/foo/bar/file.xyz are clearly dodgy > on Win32, please try the attached script which will change them to > C:\foo\bar\file.xyz Here's the output (run by hand): > C:\LyX\lyx\bin>sh ../share/lyx/scripts/convertdefault.sh jpg:C:/LyX/Documents/ha > ppy.jpg ppm:C:/LyX/lyx/tmp/lyx_tmpdir604a01532/happy.ppm > ../share/lyx/scripts/convertdefault.sh invoked as: > jpg:C:/LyX/Documents/happy.jpg ppm:C:/LyX/lyx/tmp/lyx_tmpdir604a01532/happy.ppm > $arg1 is jpg:C:\LyX\Documents\happy.jpg > $arg2 is ppm:C:\LyX\lyx\tmp\lyx_tmpdir604a01532\happy.ppm > ../share/lyx/scripts/convertdefault.sh ERROR > Unable to find file "C:\LyX\lyx\tmp\lyx_tmpdir604a01532\happy.ppm" The target file happy.ppm was created and is in fact sitting in the temp directory when the "Unable to find ..." message is generated. The path and file name are correct. > > I understand that Win32 machines often have a 'convert.exe' file that > converts file partitions to/from FAT32. Perhaps this is a PATH issue > and the wrong 'convert' is getting called. No, the conversion is being done correctly, so it must be the correct "convert" program. I poked around with the script myself over the weekend, and may have come up with at least a partial answer. We seem to be dealing with not one but two problems here. The first is that Ruurd supplies a Windows port of sh but not a port of cut. Thus on a "virgin" installation of Ruurd's port, the line FILE=`echo $2 | cut -d ':' -f 2` in convertDefault.sh will fail silently (because cut is not found), setting FILE to a null value. The subsequent test -f $FILE || FSTATUS=1 must then succeed (trivially) and the script proceeds on the (untested) assumption that the converted file is where it is supposed to be -- which in fact it is in my test case. (If I comment out the line that calls cut, graphics display in LyX. Of course, this will go awry the day that a conversion actually fails.) The other confounding factor is that my machine's not a virgin; I have Cygwin installed, and Cygwin *does* supply cut.exe. So on my machine the call to cut works -- which turns out to be unfortunate, because argument $2 contains a drive specification (ppm:C:/LyX/...). The second colon causes the -f 2 argument to return C as the value of $FILE, and then the test fails. I tried -f 3 and -f 2-, and neither worked. What finally worked (I think) was FILE=`echo $2 | cut -d ':' -f 3` FILE="/c/$FILE" and then the rest of the script as is. Disclaimer here: I grew up in the PC world and speak very limited amounts of Unix. Someone who actually understands sh should check this over. -- Paul ************************************************************************* Paul A. Rubin Phone: (517) 432-3509 Department of Management Fax: (517) 432-1111 The Eli Broad Graduate School of Management E-mail: [EMAIL PROTECTED] Michigan State University http://www.msu.edu/~rubin/ East Lansing, MI 48824-1122 (USA) ************************************************************************* Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. J. W. v. GOETHE
