bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] .apl.history


From: Juergen Sauermann
Subject: Re: [Bug-apl] .apl.history
Date: Fri, 04 Jul 2014 14:47:44 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi David et al.,

I believe your proposal below does not work in general. Often (if not to say normally) GNU APL is installed by root, so $HOME would be /root. I believe most system administrators would not like programs to install config files there (and it would not even be readable by
other users).

And likewise, most users will not like it if a new GNU APL installation overrides their preferences file.

The current strategy is to not install anything in any $HOME directory and I believe that is good so. The preferences file below /etc belongs to the installation while the preferences file in $HOME belongs to the user. That is a clear cut of responsibilities and also of file access permissions.


And then there is the question of the default value for READLINE_HISTORY_PATH in the preferences file. The default value of libreadline for its history is ~/.history. That was the first thing that annoyed me because it puts the histories of different
programs into the same history file. Rather useless IMHO.

The next level would be a per binary file for the history like ~/.apl-history as proposed by Blake and also preferred by Elias. On the other hand, apparently David and definitely myself prefer the current solution which is the current directory for the history file. The way I am working is to have different directories for different APL related tasks. And when I work on one task then I do NOT want the history of other tasks to be mixed together. I sometimes open the history file to see what I did before. With a mix of different
APL sessions in the same file that would be close to impossible.

Another complication with $HOME/.apl-history is that the preferences file is a plain text file and not a shell script. Therefore environment variable expansion like $HOME would require a parser for the preferences file which understands $HOME (or ~ for that matter).

Compared to that, all that those who want everything in one file need to do is to put the location of that file into the user's preferences file (the one below $HOME). As we have seen earlier different users seem to have different preferences as to where the preferences file should be located (under $HOME/.gnu-apl/ vs. $HOME/.config/gnu-apl). That tells me that different people have different opinions about such things and that it is better to leave it to the
user to set things up herself.

For all those reasons, I believe it is better to leave things as they are.

/// Jürgen


On 07/02/2014 09:08 PM, David B. Lamkins wrote:
While I agree that $HOME/.apl-history is more generally useful, I can
also make a case for having the history file's location be relative to
the working directory:

Assume that you're a consultant or contractor working on APL projects
for a number of clients. You cd to the directory for a client's project,
start up APL, and do your work for that client. The history file remains
specific to that client/directory, which is probably what you'd prefer
in that situation.

Here's my proposal...

Have the installer and the Makefile's install target do the following:
   1. Confirm that $HOME exists.
   2. Install $HOME/.gnu-apl/preferences from the template.
   3. Edit the user's preference file to set READLINE_HISTORY_PATH using
the absolute path to $HOME.

This should address Blake's concern about keeping the installation
process simple, provide what (I think) is the more useful general case
while not precluding other choices, and have a reasonable fallback on
platforms that don't set $HOME.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]