[tex-live] windows multiple tl versions

[Siep Kroonenberg]

On Tue, Dec 27, 2011 at 02:06:05AM +0100, Reinhard Kotucha wrote:
> On 2011-12-26 at 22:03:44 +0100, Siep Kroonenberg wrote:
> 
>  > When you use TL from the command-line there is no problem if you are
>  > willing to manage the searchpath yourself. Also, 2010 and 2011 each
>  > get their own uninstall registry entries so you can uninstall them
>  > in either order.
>  > 
>  > But there is a conflict with associating a file type with a program.
>  > 2010 and 2011 associate extensions with the same filetype, but
>  > associate the filetype with different programs viz. the 2010- and
>  > the 2011 versions.
> 
> Which extensions are concerned?  I doubt that there are many.
> TeX Live doesn't provide many programs that can be started by a mouse
> click.

The filetypes are TL.TeXworks.edit, TL.PSView.view,
TL.DVIOUT.view and TL.bitmap2eps.convert, with corresponding
extensions.

>  > The last one installed wins.
> 
> This is fine.  The question is whether there are critical
> constellations.  Suppose that I've installed TL-2010 after TL-2011 but
> I've modified $PATH manually in order to run programs from TL-2011 by
> default.
> 
> When creating a .ps file, the programs tex.exe and dvips.exe are found
> in the TL-2011 tree according to the $PATH setting.  But when I click
> on the created .ps file in the Exploder, ps_view from TL-2010 is
> launched.  But this is absolutely harmless.
> 
> Is a more critical situation thinkable?

I already mentioned a garbled searchpath for TW, but nothing else
comes to my mind.

>  > Should we add a release tag to the file types?
> 
> What do you have in mind?  Making use of the fact that assigning
> file-name extensions to programs is a two-step approach on Windows
> (assoc/ftype)?

For next year, we could simply append `.2012' to these filetypes.

Association with an extension can either be as primary filetype or
as an entry in the OpenWithProgIds list, in which case it is
available via the right-click menu.

For 2011, overriding the filetype of an extension moved the former
primary filetype to an OpenWithProgIds entry. For 2012, we could
always override the unversioned TL... filetypes in this way. I am
pretty sure that it is no big deal.

> As someone who enjoyed using fvwm2 from the beginning, I've no
> experience with KDE or Gnome.  I'm wondering whether the situation is
> better on Linux.  I don't have KDE or Gnome installed, but I fear that
> they inherited the file association mess from Windows because their
> declared goal is to make Linux as inconvenient as Windows.
> 
> Do KDE and Gnome insist on absolute paths too?  That would be strange,
> but not necessarily surprising.

Looking around on a Ubuntu live-cd system, it appears that gnome
implementations of Windows inconveniences are slightly saner than
the originals; I found e.g. a text file
~/.local/share/applications/mimeapps.list with

[Added Associations]
...
image/jpeg=eog.desktop
...

and a file /usr/share/applications/eog.desktop with:

...
Exec=eog %U
Icon=eog
...

>  > I guess TexWorks might get confused if you do not modify its
>  > searchpath. It seems to compose its searchpath from its own location
>  > and from the Windows searchpath, so the 2010 TeXWorks might end up
>  > using the 2010 perl with the 2011 <root>bin/win32.
> 
> Is there any reason why TeXworks maintains absolute paths instead of
> simply relying on what's in $PATH?  I.e. call tex instead of
> /path/to/tex. 

TeXWorks apparently does not rely on absolute paths, but composes
its own path on-the-fly from among other things also the inherited
searchpath.

-- 
Siep Kroonenberg