Open GoogleCodeExporter opened 9 years ago
These filenames are coming straight from your latex binary. If you were to
just go to your directory and run
pdflatex -recorder -interaction=batchmode recovery
and then to do
cat recorder.fls
You would find that those path names are coming from that file. So, I can't
change the way that your latex is outputting file paths. It looks like this is
not a cygwin problem, but is rather due to a change in your tex distribution.
Does that sound right to you?
Original comment by shiblon
on 1 Feb 2011 at 4:15
You are right. I've changed to use MiKTex which is a native windows
implementation of tex. So this is not really a latex-makefile issue. Thanks for
the hint.
So you may just close the issue as invalid. I would just like to know if you
can tell me the place in the Makegile that I can insert call to cygpath to
convert the path generated by MiKTex to cygwin path.
Thanks again!
Original comment by xuewen.w...@gmail.com
on 1 Feb 2011 at 4:28
I hadn't heard of cygpath before today. How does it work?
We can probably fix this in the makefile, or at least provide a usable
workaround.
Original comment by shiblon
on 1 Feb 2011 at 4:35
cygpath is a cygwin program to convert windows native path to cygwin path.
For example:
cygpath -u "C:/Program Files/MiKTeX 2.9/fonts/type1/urw/times/utmr8a.pfb"
will return
/cygdrive/c/Program Files/MiKTeX 2.9/fonts/type1/urw/times/utmr8a.pfb
If you can fix this in the makefile, that would be great since MiKTex is much
easier to use and more up to date than tetex packaged in cygwin which is no
more actively maintained (and replaced by texlive in upstream).
Original comment by xuewen.w...@gmail.com
on 1 Feb 2011 at 4:46
OK - let's try this by hand and see if it works.
After generating your recovery.d file, open it up and do the following:
- move ".SECONDEXPANSION" to the top fo the file, just under the #vim comment
- Change every line to call cygpath. An example is given below:
recovery.aux recovery.aux.make recovery.d recovery.pdf: $$(shell cygpath -u
"C:/Program Files/MikTex 2.9/tex/latex/base/article.cls")
If that works, we're set. I suspect that it won't, though, because we still
have a colon parsing issue. Nevertheless, I'm really hoping that does it.
Original comment by shiblon
on 1 Feb 2011 at 4:55
OK. I've replaced recovery.d with the following:
# vim: ft=make
.SECONDEXPANSION:
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\
2.9/tex/latex/base/article.cls)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\
2.9/tex/latex/base/fontenc.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\
2.9/tex/latex/base/inputenc.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\
2.9/tex/latex/fancyhdr/fancyhdr.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\
2.9/tex/latex/graphics/color.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\
2.9/tex/latex/psnfss/times.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u
"$(shell cygpath -s -w E:/clean/Docs/Devel/recovery.tex)")
Due to the space inside the directory name, I have to convert at first the
windows path to dos 8.3 format and then use cygpath -u.
It seems that it does produce the necessary recovery.pdf without error. So
there may have a chance that you can fix this in the makefile!
Thanks in advance!
Original comment by xuewen.w...@gmail.com
on 1 Feb 2011 at 5:35
OK - one last question.
Does it work if you do the following?
# vim: ft=make
do-cygpath = $(shell cygpath -u $(shell cygpath -s -w "$1"))
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/article.cls)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/fontenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/inputenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/fancyhdr/fancyhdr.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/graphics/color.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/psnfss/times.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,E:/clean/Docs/Devel/recovery.tex)
.SECONDEXPANSION
Original comment by shiblon
on 1 Feb 2011 at 6:38
Unfortunately, using do-cygpath doesn't work, and gave error like:
cygpath: cannot create short name of C:\Program\ Files\MiKTeX\
2.9\tex\latex\base\article.cls
Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
cygpath [-c HANDLE]
cygpath [-ADHOPSW]
cygpath [-F ID]
Convert Unix and Windows format paths, or output system path information
Output type options:
-d, --dos print DOS (short) form of NAMEs (C:\PROGRA~1\)
-m, --mixed like --windows, but with regular slashes (C:/WINNT)
-M, --mode report on mode of file (binmode or textmode)
-u, --unix (default) print Unix form of NAMEs (/cygdrive/c/winnt)
-w, --windows print Windows form of NAMEs (C:\WINNT)
-t, --type TYPE print TYPE form: 'dos', 'mixed', 'unix', or 'windows'
Path conversion options:
-a, --absolute output absolute path
-l, --long-name print Windows long form of NAMEs (with -w, -m only)
-p, --path NAME is a PATH list (i.e., '/bin:/usr/bin')
-s, --short-name print DOS (short) form of NAMEs (with -w, -m only)
-C, --codepage CP print DOS, Windows, or mixed pathname in Windows
codepage CP. CP can be a numeric codepage identifier,
or one of the reserved words ANSI, OEM, or UTF8.
If this option is missing, cygpath defaults to the
character set defined by the current locale.
System information:
-A, --allusers use `All Users' instead of current user for -D, -O, -P
-D, --desktop output `Desktop' directory and exit
-H, --homeroot output `Profiles' directory (home root) and exit
-O, --mydocs output `My Documents' directory and exit
-P, --smprograms output Start Menu `Programs' directory and exit
-S, --sysdir output system directory and exit
-W, --windir output `Windows' directory and exit
-F, --folder ID output special folder with numeric ID and exit
Try `cygpath --help' for more information.
It seems that there is quoting issue. I'm sorry that I don't know enough shell
to understand how to fix it but indeed defining a function can simplify the
code a lot.
Original comment by xuewen.w...@gmail.com
on 1 Feb 2011 at 8:48
Interesting. What if the function is defined differently (without quotes):
do-cygpath = $(shell cygpath -u $(shell cygpath -s -w $1))
Original comment by shiblon
on 1 Feb 2011 at 8:55
Without quotes, I got the same error as from the beginning:
recovery.d:4: *** target pattern contains no `%'. Stop.
Original comment by xuewen.w...@gmail.com
on 1 Feb 2011 at 9:09
Oh, of course!
But, interestingly, if I understood the one working fix properly, it looks like
you can do this:
do-cygpath = $(shell cygpath -u "$(shell cygpath -s -w $1)")
If that doesn't work, it's back to the drawing board. Also, the
.SECONDEXPANSION may actually be necessary at the top of the file, there. I
wasn't sure whether it was needed or not, but it very well may be.
Original comment by shiblon
on 2 Feb 2011 at 9:17
OK. The following works:
# vim: ft=make
do-cygpath = $(shell cygpath -u "$(shell cygpath -s -w $1)")
.SECONDEXPANSION:
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/article.cls)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/fontenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/inputenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/fancyhdr/fancyhdr.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/graphics/color.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/psnfss/times.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call
do-cygpath,E:/clean/Docs/Devel/recovery.tex)
Original comment by xuewen.w...@gmail.com
on 3 Feb 2011 at 9:01
Thanks - I'll see what I can do with this. I think I'll have a variable that
you can set to do path manipulation. Or I could check for the presence of the
cygpath binary and use it if it's there.... What do you think would be best?
Also, if you remove .SECONDEXPANSION, does the above still work?
Original comment by shiblon
on 3 Feb 2011 at 3:22
It seems that it works even if I remove .SECONDEXPANSION.
Actually, even if on cygwin, if one is using the latex from the cygwin package,
no path manipulation is needed. It is only when the makefile is used on cygwin
with native windows tex implementation like MiKTex that doesn't work. It is
possible to check this particular case automatically, but a variable to set for
path manipulation works also for me.
Thanks in advance!
Original comment by xuewen.w...@gmail.com
on 3 Feb 2011 at 3:37
And thanks for your patience as we try to find the right answer here :)
You mention that it is possible for us to check for miktex and do this
automatically - if that's the case, I would much prefer it, since one of the
goals of the makefile is that it require no fiddling to make it work for most
cases.
I'm assuming that calling cygpath within cygwin on a standard unix-like
pathname does nothing? If so, then I can just call cygpath if it exists, and
not call it if it doesn't....
Original comment by shiblon
on 3 Feb 2011 at 4:01
If MikTex can be automatically detected and then cygpath called properly on
path returned by MiKTex, that would be the best solution.
cygpath -u called on unix path doesn't change it.
Thanks!
Original comment by xuewen.w...@gmail.com
on 3 Feb 2011 at 4:08
rbe8fd3c38afd contains the fix, and I've attached the generated makefile here.
Give it a try, and let me know how it works for you.
Original comment by shiblon
on 3 Feb 2011 at 4:20
Attachments:
Just did a quick test and it works! Thanks for the quick fix!
Original comment by xuewen.w...@gmail.com
on 3 Feb 2011 at 4:45
Glad it worked for you!
Original comment by shiblon
on 3 Feb 2011 at 5:30
This fix has introduced a regression for my configuration. I've verified that
rc9 works for me, but rc10 does not. The makefile works as normal, but now it
spits out this error after every invocation:
which: no cygpath in
(/usr/local/lf6480/bin:/auto/users/foo/local/jre1.6.0_21/bin:~/src/:/auto/users/
foo/local/texlive/2010/bin/x86_64-linux:/auto/users/foo/local/bin:/usr/kerberos/
bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/pathscale/bin:/auto/share/b
in)
Original comment by onion.av...@gmail.com
on 2 Mar 2011 at 5:33
Sorry, I forgot to state that I'm running Linux (RHEL4) so I don't use cygwin.
Original comment by onion.av...@gmail.com
on 2 Mar 2011 at 5:33
I'm looking at this now.
Original comment by shiblon
on 2 Mar 2011 at 8:06
Try the attached -let me know if it works for you.
Original comment by shiblon
on 2 Mar 2011 at 8:08
Attachments:
Yup, that works. Thanks!
Original comment by onion.av...@gmail.com
on 2 Mar 2011 at 9:22
Closing out again and uploading version 2.2.0-rc11
Original comment by shiblon
on 3 Mar 2011 at 4:09
I had few more problems with make 3.81 on cygwin.
USE_CYGPATH was not set, so I changed it to use uname -o
The bib-file needed also to be passed through path-norm, so I added this to
get-bibs
Patch attached, seems to work for me
Original comment by ferr...@gmail.com
on 7 Mar 2011 at 9:03
Attachments:
Before I apply this, I just want to make sure that I understand what is broken
about the old approach.
It looks like I made the classic mistake of diverting both stdout and stderr to
/dev/null, instead of just one of them. So, I believe that you can get the
USE_CYGPATH working properly by changing it to the following:
USE_CYGPATH := $(if $(shell $(WHICH) $(CYGPATH) 2>/dev/null),yes,)
Can you check that the above works?
The bib changes are useful. I wonder what else we might have missed....
Original comment by shiblon
on 9 Mar 2011 at 9:35
Oops - marking Open.
So, two problems:
1) fix USE_CYGPATH
2) fix bib files to undergo path normalization.
Original comment by shiblon
on 9 Mar 2011 at 9:36
By the way, the sed fix won't work properly unless cygpath returns multiple
outputs, one for each input. Additionally, if we're going to edit the sed
script, we want to do it on the line before s!^!$2: !, not the line after. I
don't have anywhere to run cygpath to test how it works, so it would be nice to
verify that calling it this way does the right thing:
cygpath C:\dir1\file1.txt C:\dir2\file2.txt
Ideally, it will convert all of its arguments and generate one filename each.
If not, I need to think carefully about how to make it work properly, probably
using a shell loop.
Original comment by shiblon
on 9 Mar 2011 at 9:42
Where did we end up here?
Original comment by shiblon
on 22 Apr 2011 at 3:47
cygpath "C:\dir1\file1.txt" "C:\dir2\file2.txt" returns
/cygdrive/c/dir1/file1.txt
/cygdrive/c/dir2/file2.txt
For me. It seems that it works as you expected :)
Original comment by xuewen.w...@gmail.com
on 22 Apr 2011 at 4:03
OK - sorry I'm so slow. Yes, that's exactly what I hoped it would do.
So, just to refresh my leaky memory, what remains is to just apply your patch?
Original comment by shiblon
on 9 May 2011 at 8:27
Give the attached version a try and let me know how it works. Relevant changes
in r74fed3f4dd3c.
Original comment by shiblon
on 9 May 2011 at 8:40
Attachments:
Were you able to try the attachment to see if it works properly? I'd love to
know how it's going for you.
Original comment by shiblon
on 14 Jun 2011 at 3:52
Original issue reported on code.google.com by
xuewen.w...@gmail.com
on 1 Feb 2011 at 2:40