Calibre in Windows path

banjomike · 09-01-2009, 05:39 PM

Hi,
I couldn't see a reference to this in the FAQ so, does Calibre NEED to be in the Windows path?

After installation of Calibre can I remove the reference from the path.

I'm just a bit paranoid about system level changes.

kovidgoyal · 09-01-2009, 05:42 PM

You can remove it, as far as I know nothing should break.

banjomike · 09-01-2009, 05:44 PM

Thanks, if any happens I'll let you know.

pepak · 09-02-2009, 11:09 AM

It got changed?

In 0.6.3 and around, you had to keep Calibre in path, otherwise e.g. command line conversion wouldn't work :-(

kovidgoyal · 09-02-2009, 11:20 AM

Quote:

Originally Posted by pepak

It got changed?

In 0.6.3 and around, you had to keep Calibre in path, otherwise e.g. command line conversion wouldn't work :-(

Well obviously if it's not in path command line tools wont work?

pepak · 09-03-2009, 11:42 AM

Quote:

Originally Posted by kovidgoyal

Well obviously if it's not in path command line tools wont work?

Why "obviously"? There's nothing obvious about it. Why should d:\calibre\ebook-convert.exe file1 file2 work if, and only if, either Calibre's directory is current working directory or is referenced by path? That's the problem, that you have to use path even though absolute paths should be sufficient. I personally posted a (now closed) ticket about this!

kovidgoyal · 09-03-2009, 12:02 PM

Quote:

Originally Posted by pepak

Why "obviously"? There's nothing obvious about it. Why should d:\calibre\ebook-convert.exe file1 file2 work if, and only if, either Calibre's directory is current working directory or is referenced by path? That's the problem, that you have to use path even though absolute paths should be sufficient. I personally posted a (now closed) ticket about this!

Because windows uses PATH to search for dlls. You really should open a ticket with Microsoft

pepak · 09-03-2009, 12:53 PM

1) It works with all Windows programs I know of just fine.

2) In Calibre, it doesn't work only with files inside library.zip, which isn't a part of Windows library system so there is little reason why it should be limited by its deficiencies, if there are any. The problem lies in some Python's library-loading function you use in Calibre, NOT in Windows' libary handling.

pepak · 09-03-2009, 12:57 PM

Quote:

Originally Posted by kovidgoyal

Because windows uses PATH to search for dlls.

Technically, Windows use these locations to search for DLLs:
- application's directory
- system directory
- 16bit system directory
- Windows directory
- current directory
- directories in PATH

Source (and the source is actually true)

The problem with Calibre is that it doesn't use application's directory for some of its searches (those referencing the contents of library.zip - curiously, it finds library.zip just fine)

kovidgoyal · 09-03-2009, 01:24 PM

Quote:

Originally Posted by pepak

2) In Calibre, it doesn't work only with files inside library.zip, which isn't a part of Windows library system so there is little reason why it should be limited by its deficiencies, if there are any. The problem lies in some Python's library-loading function you use in Calibre, NOT in Windows' libary handling.

OK Open a bug with py2exe in that case

pilotbob · 09-04-2009, 12:04 AM

Quote:

Originally Posted by kovidgoyal

Because windows uses PATH to search for dlls. You really should open a ticket with Microsoft

That's not true. Most languages that I have worked with on windows will always look for binaries in the current folder first, then the path. Unless of course it is COM, then it will look for the class id in the registry and load the DLL from there.

BOb

kovidgoyal · 09-04-2009, 12:57 AM

It's nowhere near that simple. The number of layers that Microsoft has added in an effort to make future code more robust while maintaining backward compatibility is no joke. For example: Have a file with an ending of .local with the same name as the exe will cause the dynamic linker to look in the same directory as the executable first. Then there's the whole rigamarole with SxS. Then there are at least a couple of environment variables, one of which is PATH that influence the algorithm used by the dynamic linker. It's a completely byzantine mess...

pilotbob · 09-04-2009, 12:55 PM

Quote:

Originally Posted by kovidgoyal

Then there are at least a couple of environment variables, one of which is PATH that influence the algorithm used by the dynamic linker. It's a completely byzantine mess...

Yes, I agree. But, MS doesn't have the luxury of pulling an Apple and dropping all the legacy backward compatible support and shims that are in the OS which make it so bloated and convoluted.

BOb

kovidgoyal · 09-04-2009, 12:58 PM

Quote:

Originally Posted by pilotbob

Yes, I agree. But, MS doesn't have the luxury of pulling an Apple and dropping all the legacy backward compatible support and shims that are in the OS which make it so bloated and convoluted.

BOb

Oh I'm not blaming Microsoft. They don't really have a choice and I appreciate the fact that calibre built on XP still runs on 7 without any modifications, unlike OS X where I had to fix it for Leopard and now again for Snow Leopard.

09-01-2009, 05:39 PM	#1
banjomike Addict Posts: 319 Karma: 397404 Join Date: Aug 2009 Location: UK Device: PRS-505,DSlibris,nook Glow & HD+,Tab S2,Moon+,Clara,Clara Colour	Calibre in Windows path Hi, I couldn't see a reference to this in the FAQ so, does Calibre NEED to be in the Windows path? After installation of Calibre can I remove the reference from the path. I'm just a bit paranoid about system level changes.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Windows 7 doesn't like my calibre?	jlonghurst	Calibre	3	10-13-2010 09:31 AM
Default Path Calibre	Themus	Calibre	2	08-12-2010 10:44 PM
Calibre 0.7.x can't open UNC path	adfrad	Calibre	4	07-07-2010 08:31 AM
[Bug] Calibre using all lower case path names	krunk	Calibre	0	05-01-2010 02:58 PM
Specify liberary path in command line when launching calibre	rollercoaster	Calibre	2	03-04-2010 12:08 AM

09-01-2009, 05:42 PM	#2
kovidgoyal creator of calibre Posts: 45,200 Karma: 27110894 Join Date: Oct 2006 Location: Mumbai, India Device: Various	You can remove it, as far as I know nothing should break.

09-01-2009, 05:44 PM	#3
banjomike Addict Posts: 319 Karma: 397404 Join Date: Aug 2009 Location: UK Device: PRS-505,DSlibris,nook Glow & HD+,Tab S2,Moon+,Clara,Clara Colour	Thanks, if any happens I'll let you know.

09-02-2009, 11:09 AM	#4
pepak Guru Posts: 610 Karma: 4150 Join Date: Mar 2008 Device: Sony Reader PRS-T3, Kobo Libra H2O	It got changed? In 0.6.3 and around, you had to keep Calibre in path, otherwise e.g. command line conversion wouldn't work :-(

09-03-2009, 12:53 PM	#8
pepak Guru Posts: 610 Karma: 4150 Join Date: Mar 2008 Device: Sony Reader PRS-T3, Kobo Libra H2O	1) It works with all Windows programs I know of just fine. 2) In Calibre, it doesn't work only with files inside library.zip, which isn't a part of Windows library system so there is little reason why it should be limited by its deficiencies, if there are any. The problem lies in some Python's library-loading function you use in Calibre, NOT in Windows' libary handling.

09-04-2009, 12:57 AM	#12
kovidgoyal creator of calibre Posts: 45,200 Karma: 27110894 Join Date: Oct 2006 Location: Mumbai, India Device: Various	It's nowhere near that simple. The number of layers that Microsoft has added in an effort to make future code more robust while maintaining backward compatibility is no joke. For example: Have a file with an ending of .local with the same name as the exe will cause the dynamic linker to look in the same directory as the executable first. Then there's the whole rigamarole with SxS. Then there are at least a couple of environment variables, one of which is PATH that influence the algorithm used by the dynamic linker. It's a completely byzantine mess...

Advert

Advert