zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: adding history logging "automagically" :)
Date: Mon, 09 Jul 2007 17:47:50 -0700	[thread overview]
Message-ID: <070709174750.ZM11342@torch.brasslantern.com> (raw)
In-Reply-To: <3cb6e920707091041t3b3f5c1cy7d7b08e6028c22f9@mail.gmail.com>

On Jul 9,  1:41pm, Joe D wrote:
}
} So in a nutshell, all I want to do is modify 'zsh' source

Ick.  Don't do that.

} to always do the following options automatically (regardless of if
} these lines are present or not):
} 
} HISTSIZE=1000
} SAVEHIST=1000
} HISTFILE=/opt/some_location/.user.log
} setopt APPEND_HISTORY
} setopt SHARE_HISTORY
} setopt INC_APPEND_HISTORY

I don't think you want SHARE_HISTORY - that means the shells pass the
current history around among themselves while they are running.  You
don't really want Alice to see Bob's commands, do you?

Also I think APPEND_HISTORY is redundant with INC_APPEND_HISTORY, but
it probably won't hurt anything.

In any case you're going to be defeated here by a zsh security feature
that prevents the shell from using a history file that is owned and/or
writable by someone else.  Each shell will try to assume ownership of
the file and remove group/other write permission, so there will be a
mad scramble of unlinking/recreating of the file as each shell notices
that one of the others has tried to grab it.  That's probably why you
can't find the file even though you can find the lock.

The best you might be able to do is

HISTFILE=/opt/some_location/.$USER.log

so that every user has his or her own history file in some_location.

Beyond that, I suggest placing

if [[ $USER = (list|of|problem|users) ]]; then 
  readonly HISTSIZE=1000
  readonly SAVEHIST=1000
  readonly HISTFILE=/opt/some_location/.$USER.log
  setopt APPEND_HISTORY
  setopt INC_APPEND_HISTORY
  setopt EXTENDED_HISTORY
fi

in /etc/zshenv, which is always run (unless the shell was configured
with --disable-zshenv).  Using EXTENDED_HISTORY will give you time
stamps on the entries, so you can combine and sort the users' log
files to determine the order of events.

They could still deliberately mess you up by frobbing those setopts
later ... so I suppose if you must hack the source, the place to put
your dosetopt() calls would be in Src/init.c, in loop(), with an
"if (toplevel)" test protecting them.  But if your users are so badly
behaved as to ignore your instructions to leave those options alone,
you have worse problems than just tracking down what happened when.


  reply	other threads:[~2007-07-10  0:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-09 17:41 Joe D
2007-07-10  0:47 ` Bart Schaefer [this message]
2007-07-10  1:27   ` Joe D

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=070709174750.ZM11342@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).