Re: ~/.localtime ?

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

Just a few comments; I'm not opposing to the idea per se, but...

On Thu, 01 Mar 2012 09:05:17 +0100, Andreas Jaeger <aj@suse.com> wrote:
> Currently it's only possible to change the timezone system wide and you 
> need to be root to do so.
> 
> While it's possible to change the timezone for a user with the TZ 
> variable, this does not have any effect on running programs. What do you 
> think of adding support for a user specific .localtime file that allows 
> the user to set his own timezone?

As you're basically saying, this is not a problem with TZ in particular,
but generally with environment variables.  These are very useful for
passing information for on-the-spot invocation (for example,
``LC_MESSAGES=C man [something]''), but not suitable if that information
is to be changed *externally* later on.

I totally understand your motivation for ``changing TZ'' during a
process' life time.  But the same mechanism would surely be useful for
all the LC_* ones, too, and probably more, including non-standard ones.

Generalizing this from the precedent TZ where there is a /etc/localtime
*file* already, wouldn't it be nice if the *environment variables
themselves* could be changed?  The question is whether applications are
prepared for that -- apart from caching of getenv results, one current
practice seems to assume that any two getenv ("TZ") calls will return the
same result as long as the process itself doesn't modify its environment.

If the two-getent-calls-but-different-results problem is not a real
problem -- just thinking aloud -- instead of just having a ~/.localtime,
what about having a folder ~/.env, where subfolders ~/.env/[PID] can be
created, and then files inside these.  Then, a getenv ("TZ") call would
look if the original environ's value has been overridden by
~/.env/[PID]/TZ (for the process) or ~/.env/TZ (generally).  (For cleanup
handling of ~/.env/[PID], ~/.env would probably have to be implemented by
a kernel virtual file system.)

And, on GNU Hurd, there's a mechanism implemented for allowing an
external process to change another process' set of environment variables
(if having permission to do so):

    $ msgport --help
    Usage: msgport [OPTION...]  CMD [ARG...]
    Send messages to selected processes
    
     Commands:
          --cdroot               Change cwd to root directory
          --chdir=DIR, --cd=DIR  Change current working directory
          --chroot=DIR           Change current root directory
          --clearenv             Clear environment
          --getenv[=VAR], --printenv[=VAR]
                                 Get environment variable
          --getroot              Print current root directory
          --pwd, --getcwd        Print current working directory
          --setenv=VAR VALUE     Set environment variable
          --setfd=FD FILE [rwxa] Change file descriptor
          --stderr=FILE [rwxa]   Change standard error
          --stdin=FILE [rwxa]    Change standard input
          --stdout=FILE [rwxa]   Change standard output
          --umask[=MASK]         Change umask
    
     Process selection:
      -L, --login[=LID]          Processes from the login collection LID (which
                                 defaults that of the current process)
      -p, --pid=PID              The process PID
      -P, --pgrp=PGRP            Processes in process group PGRP
      -S, --session[=SID]        Processes from the session SID (which defaults to
                                 that of the current process)
    [...]

To my knowledge, this has not yet been exercised a lot, though, so no
empirical values about its real-world usability.


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature