"Invalid control sequence" e...

Help
2012-02-13
2012-10-17
  • John Perkins
    John Perkins
    2012-02-13

    We are trying to deploy MiKTeX 2.9 to a number of managed Windows 7 (64-bit,
    if it matters) workstations. After installing, users get an "invalid control
    sequence" error when running any MiKTeX programs as themselves.

    The installation is done as an Administrator user. I tried to run
    C:\Program Files (x86)\MiKTeX 2.9\miktex\bini\initexmf.exe --dump=<pkg>
    where <pkg> is etex, latex, pdfetex, pdflatex, pdftex and tex to generate
    format files.

    I did find the MiKTeX installer wants to install the texmf tree in
    C:\ProgramData\MiKTeX\2.9, and non-priviledged users are not allowed to write
    to that directory. In an attempt to get around this, I tried installing with
    the common-data and common-config directories moved to C:\MiKTeX\2.9 At least
    users are able to write generated package and format files to this directory
    tree.

    I haven't found any solution for getting around the "invalid control sequence"
    errors, though.

    Any suggestions from the gurus here?

    John

     
  • U_Fischer
    U_Fischer
    2012-02-15

    I don't understand why you didn't let miktex use the default locations. In
    multiuser mode the restricted user would have get local trees (UserConfig and
    UserData) in their user profiles for packages installations and format files.
    There is no need for them to be able to write in the main installation tree or
    in CommonData and CommonConfig.

    I never saw an "invalid control sequence" error and I have a lot of doubts
    that you actually quoted the error message correctly. You certainly didn't
    give informations about it (e.g. which application actually issue the error
    message).

    http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

    Ulrike Fischer

     
  • John Perkins
    John Perkins
    2012-02-15

    I have tried installing with the standard and custom common-data and common-
    config paths in an effort to narrow down whether the problem was in accessing
    those file directories.

    The issue I have is when I run "latex" or "latex.exe", the error reported on
    the screen is "latex.exe: Invalid control sequence.", then the program quits.
    I can run "latex <filename>" and get the exact same error.

    The exact same error is returned (except for the program name at the beginning
    of the error) for tex.exe, pdftex.exe, pdflatex.exe and etex.exe.

    This error does not occur for the administrator user, but it does occur non-
    administrator users on the system (mentioned in my first post). The
    installation was done for "all users" when initially installed; a complete
    MiKTeX installation was selected at install time.

    John

    John

     
  • John Perkins
    John Perkins
    2012-02-15

    Error being reported is coming from Libraries/MiKTeX/Core/config.cpp line
    1689.

     
  • John Perkins
    John Perkins
    2012-02-15

    Progress: turns out the problem has to do with users that use roaming profiles
    where %localappdata% is removed at logout. MiKTeX does not handle this
    situation very well.

    To get MiKTeX working and avoid the above "Invalid control sequence" error
    mentioned above, the user can run MiKTeX 2.9 -> Maintenance -> Settings and
    "Refresh FNDB". This rebuilds .fndb files in
    %localappdata%\MiKTeX\2.9\miktex\data\le

    The problem comes in when machine policy settings call for any profile data on
    the local disk to be removed at logout (after any roaming profile data is
    sync'ed to the fileserver). All data in %localappdata% is lost.

    Is there a way to rebuild the .fndb files in %localappdata% at the command
    line, rather than using the GUI mo.exe program? Or is there a registry key
    that can be set to direct MiKTeX to use an alternate location to store such
    data, such as %appdata% (roaming profile application data that is sync'ed at
    logout)?

    John

     
  • U_Fischer
    U_Fischer
    2012-02-16

    You can update the fndb on the command line with initexmf -u, see
    documentation of miktex. If the users have local font maps or use xetex they
    perhaps also should call updmap or fc-cache. You could also regenerate the
    formats (but normally miktex regenerates them on the fly when they are
    missing.)

    You can at installation time change the location of the UserData root and e.g.
    put it in the roaming profile. But you should be aware that the root can get
    quite large over time (mine is about 400 MB but most of it is from the font
    cache of luatex) and so can slow down the logout. At a discussion last july in
    the mailing list a user at the end put it in C:\temp.
    https://sourceforge.net/mailarchive/forum.php?thread_name=16961017.3224.13109
    94362659.JavaMail.adm-moff%40moffice5.nsc.no&forum_name=miktex-users

    Ulrike Fischer

     
  • John Perkins
    John Perkins
    2012-02-16

    We do have folder redirection in place for our users' roaming profile AppData
    directory, so the fact that the UserData directory tree can grow quite large
    is not an issue in our environment.

    I tried installing with --user-data=%appdata%\MiKTeX\2.9; unfortunately this
    expands %appdata% at the time of the installation, not when the user runs
    MiKTeX programs. All users then try to use the administrator account's
    %appdata% directory as their UserData tree. This clearly will not work.

    After searching through the registry, I found key
    HKLM\SOFTWARE\Wow6432Node\MiKTeX.org\MiKTeX\2.9\Core has string value UserData
    set to the location of the UserData tree. It would be a simple fix to just
    change this registry key value to "%appdata%\MiKTeX\2.9". Unfortunately, the
    MiKTeX Options (mo.exe) binary claims this is an "invalid argument".

    Other values for this registry key value that do not work:
    %appdata%\MiKTeX\2.9 Invalid argument
    "%appdata%\MiKTeX\2.9 Invalid argument
    \%appdata%\MiKTeX\2.9 Generates UserData tree in \%appdata%\MiKTeX\2.9, where
    "%appdata%" is not expanded

    I can set this key to "L:\AppData\Roaming\MiKTeX\2.9" to get the desired
    behavior (where L: is mapped to each user's home directory, and roaming
    profile application data is redirected to the fileserver where L:\AppData maps
    to).

    Is MiKTeX not able to use shell environment variables in file locations? Or is
    there some way to escape them? I see no such reference in the MiKTeX 2.9
    Manual. :(

    John

     
  • U_Fischer
    U_Fischer
    2012-02-16

    Hm. I never had to do a multiuser install. But imho is should be possible to
    use variables with the --user-data or the switch would be rather useless.
    Perhaps you should make a bug report that "--user-data=%appdata%\MiKTeX\2.9;"
    didn't work as expected. Then Christian could tell you if or how it should
    work.

    Ulrike Fischer

     
  • John Perkins
    John Perkins
    2012-02-16

    Thank you for your assistance with this issue.

    Turns out I ran across one more issue (for which I have a work-around, but
    wanted to post it here in case other users have trouble with it). After
    installing MiKTeX 2.9 with the --user-data option set as documented above,
    texify will not run for mortal users. latex/pdflatex/etc. all work fine.

    It appears %appdata% is expanded during the installation process, the the
    UserInstall or UserConfig directory is inserted into one (or more) of the
    configuration files texify uses. As a result, when texify is run, it always
    searches the %appdata%\MiKTeX\2.9 directory for the local administrator user,
    not for the user running texify. Anyone installing a private copy of MiKTex
    (not for all users on the computer) would not run into this problem, as
    %appdata%\MiKTeX\<versioin> will resolve to the same location at run-time and
    install-time.

    The workaround in my case is to specify the --user-config and --user-install
    options, using the same path as specified in the --user-data option.

    John