[texworks] SCRIPTING: on linux say Ubuntu - script write priveledges
Paul A Norman
paul.a.norman at gmail.com
Thu May 26 02:52:30 CEST 2011
Thanks for that comprehensive answer.
On 26 May 2011 06:47, Stefan Löffler <st.loeffler at gmail.com> wrote:
> On 2011-05-24 09:08, Paul A Norman wrote:
>> Would look to putting current Xp systems into sandboxed VBoxes under
>> say Ubuntu when the time for Xp expires...
> The time for XP has expired, hasn't it? (mainstream support ended in
> 2009, anyway)
Its the security updates that are yet to finish (thats what is the
decider in a sense) and that may have been flagged by the announcement
by Balmer of Windows 8 in the last coupls of days
which got me thinking again.
> FWIW, running XP under VirtualBox on Ubuntu works. Whether it works well
> depends on your system, processor, and its ability for virtualization.
> On my PC at work, things slow down horribly when running VBox, on my
> laptop at home it works quite well (though I still wouldn't try to play
> games on it ;)).
Good to know. Strangely (to some) I've never got into games !)
>>>> After setting the ppa required
>>>> https://launchpad.net/~texworks/+archive/ppa, Using sudo apt-get
>>>> install stuff to setup TeXworks 0.5 ver813 (works really nicely), when
>>>> a user runs a Tw script from TeXworks, can the script automatically
>>>> (if Tw's preferences permissions are already set) write/read to
>>>> subdirectories of the Tw script's own directory?
>>> Yes, that should be possible in the same way as on the other OSs by default.
>>> <random rambling>
>>> Of course, the user must have read/write permissions to the files and
>>> directories in question. This is required by Linux independent of Tw.
>>> Since, by default, the resources are put under the user's home
>>> directory, this shouldn't be a problem.
>> Ok, please see point below. This is leading to what I am thinking about.
>>> Note, though, that resources
>>> provided by Tw typically are installed read-only (on my machine,
>>> anyway). I haven't investigated this yet, as it is not a problem for me
>>> (any noone else has complained yet ;)) - you wouldn't want to overwrite
>>> "official" files, anyway, would you?
>>> </random rambling>
>>>> Also I have found that when logged in under the user name established
>>>> during Ubuntu install, running TeXworks form a console produces a
>>>> version that shows the TeXworks menu items in the new Unity top frame,
>>>> however if I start TeXworks as sudo TeXworks I get a more classical
>>>> looking (similar to Windows) appearance of TeXworks layout with the Tw
>>>> menus in the program's own frame. What should I make of that please?
>>> Interesting, I haven't noticed this before, but I can confirm it. Is
>>> there a special reason to run Tw with sudo (normally, one wouldn't; btw,
>>> GUI applications should be run with gksudo, but this doesn't change the
>>> I tried with other Qt/KDE applications as well (kcalc, kdenlive), and
>>> they exhibit the same problem. So I'd say this is a problem with the
>>> interaction Qt-unity as the root user. Did you try creating a new user
>>> (different from the one created during installation) and running Tw or
>>> other Qt/KDE apps there?
> I tried the new user thing myself, it seems the behavior is exactly the
> same as with the "default" (i.e., created during installation) user. So,
> this indeed seems to be a Qt/unity bug. Since you found it, I leave it
> to you to report it (try `ubuntu-bug unity` on the command line) if you
> want to.
Done - hadn't logged in there since 2009 it seems!
>> Well this is where I am at...
>> Using a new user, would require that the scripts were copied to their
>> (new) home directory?
> Yes. The bundled scripts (and other resources) are installed
> automatically when the user runs Tw for the first time. But other
> scripts would need to be copied/linked manually.
>> Or what happens to Linux file permissions, or does TeXworks install as
>> it's own group with linux file permissions to everyone or as its in
>> HOME/USER obviously then scripts are limited to that User?
> Tw should install scripts with the permissions of the user it was run by
> (i.e., either the current user or root). It seems files are created with
> read permission for everyone, write and execute permissions for no one.
> User and group are set to the ones of the user that ran Tw.
>> That's when/why I started looking at sudo - thanks for note on gksudo,
>> it floats back into memory dimmly :)
> There's really no need for that, as everyone gets the same permissions.
> In fact, it will probably create the files with user and group root,
> which means that it's harder to change permissions (e.g., if you want to
> change a script).
>> (I like Jamie's comment when talking about gksudo , "...Man pages are
>> extremely useful for this kind of thing, a lot of the time
>> they seem to contain gibberish or language that only experienced
>> unix/linux sysadmins can understand, but this really just depends on
>> the author. ...
> How true...
> In fact, I don't understand the differences myself, I just read about it
> somewhere and thought that there probably is a (good?) reason for it ;).
>> In some educational situations say, and in other shared
>> circumstances, does each User maintain their own Script folder (yes),
>> or/and can an administrator set up a central Tw script repository on
>> each PC, or preferably even for a whole local network?
> Partly global setups are not supported at the moment. Basically, this is
> because there's no waterproof concept yet how to "merge" global and
> local settings. For instance, how to distinguish (easily) between a
> sys-admin wanting to override user settings (e.g., for security reasons)
> and one wanting to provide sensible defaults for the user to customize?
I understand the maze of thought.
Perhaps the sword (or razor) of simplicity here ...
May need two concurrent branches of Tw for the futurre?
(Perhaps achieved by whether a .so .dll plugin is present or not on
the main server?)
A full bodied personal version of Tw, and an Administrator's roll out
version - with special features for administration etc..?
> That said, the texworks-setup.ini approach still works (you can put it
> alongside the texworks binary; in the ppa install, this would be in
> /usr/bin/). This way, all users could use the same resources (preferably
> not in /usr/bin, but instead maybe in /etc/texworks or /var/texworks or
> something of the sort).
This overall, at present, this all sorts of rules out doing ppa
packages for bundles of scripts in a way? Wouldn't be sure where to
So would Tw (over long term development) respect a network UNC type
path for scripts' location? (local network centralised repository),
would I run into a nightmare of permissions issues even trying to get
such a networked located script to operate on a User's home directory?
Have been wondering to myself over the last year and a bit (trying to
balance Windows and Linux etc usage) if a simple script
reposirtories/down loader/installer/maintainer is needed in Tw itself?
Where by a user can nominate sites they want to download and maintain
scripts from, perhaps as a set format in zip modules contained in set
directory structures on script sites (which could be a local network
repository). Sort of raises itself a bit again with this discussion.
More information about the texworks