>>>>> "Pete" == Pete Forman <[EMAIL PROTECTED]> writes:
> It is moot as to whether /dev/null is suitable for HISTFILE. While it
> does have read and write permissions I would infer that the shell
> expects to be able to read back what is written. A robust
> implementation should be able to cope but can we rely on that? Maybe
> we could get away with trying "HISTFILE=/dev/null /bin/ksh" before
> "/bin/ksh" in our search for a shell.
Of course, we might end up exercising weaknesses of some implementations,
but I think that any "reasonable" implementation should be robust enough
to handle the case where the history file is modified by an external process
(typically some other ksh instance), and the /dev/null situation is really
not that different, so I think there's a fair chance that it will work
just fine.
On the other hand `HISTFILE=/dev/null /bin/ksh' will not work if the
user's SHELL is not bourne-like, which is more annoying. And I don't
think we can rely on /usr/bin/env being available, so it's not clear how
we can reliably set the env var before running ksh unless we do something
ugly like `ksh -c "HISTFILE=/dev/null exec ksh"'.
>> set -o nolog
>> Prevent the entry of function definitions into
>> the command history. See Command History List.
> That is only function definitions, not regular command line entries.
Oops, I was a bit too enthusiastic.
Stefan
