Thanks for understanding what I was saying even though I apparently have a serious issue telling PATH and HOME apart. Whenever I say PATH, read HOME.
Regards, Elias On 3 July 2014 00:40, Blake McBride <blake1...@gmail.com> wrote: > I have a current Mac OS/X system with a default configuration. $HOME is > set. > > > On Wed, Jul 2, 2014 at 11:34 AM, Elias Mårtenson <loke...@gmail.com> > wrote: > >> Are you sure of that? I'm 99% sure that PATH is always set on OSX. >> >> Regards, >> Elias >> >> >> On 3 July 2014 00:31, Blake McBride <blake1...@gmail.com> wrote: >> >>> A note from >>> http://stackoverflow.com/questions/2552416/how-can-i-find-the-users-home-dir-in-a-cross-platform-manner-using-c >>> >>> Important remark: *many people are assuming that HOME environment >>> variable is always available on Unix but this is not true*, one good >>> example would be OS X. >>> >>> On OS X when you run an application from GUI (not console) this will not >>> have this variable set so you need to use the getpwuid(). >>> >>> >>> On Wed, Jul 2, 2014 at 11:27 AM, Elias Mårtenson <loke...@gmail.com> >>> wrote: >>> >>>> Arguably, I can't think of a single situation where PATH isn't set >>>> while getpwuid would work. I could be wrong though. >>>> >>>> Regards, >>>> Elias >>>> >>>> >>>> On 3 July 2014 00:13, Blake McBride <blake1...@gmail.com> wrote: >>>> >>>>> What was recommended is to use PATH variable (as you suggest) and then >>>>> fall back to the code I gave. >>>>> >>>>> >>>>> On Wed, Jul 2, 2014 at 11:00 AM, Elias Mårtenson <loke...@gmail.com> >>>>> wrote: >>>>> >>>>>> Neat, although I believe directly looking at the PATH variable is >>>>>> more portable. It works on all Unices as well as Windows. >>>>>> >>>>>> Regards, >>>>>> Elias >>>>>> >>>>>> >>>>>> On 2 July 2014 23:54, Blake McBride <blake1...@gmail.com> wrote: >>>>>> >>>>>>> I found this for Unix/Linux systems: >>>>>>> >>>>>>> >>>>>>> #include <unistd.h>#include <sys/types.h>#include <pwd.h> >>>>>>> struct passwd *pw = getpwuid(getuid()); >>>>>>> const char *homedir = pw->pw_dir; >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 2, 2014 at 10:44 AM, Elias Mårtenson <loke...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I have to agree with Blake here. Ideally there should be a call to >>>>>>>> getenv("HOME") and if that returns non-NULL, then use the >>>>>>>> .apl_history in $HOME/.apl/apl_history or something like that. >>>>>>>> >>>>>>>> If it returns NULL, well, then fall back to current directory I >>>>>>>> suppose. >>>>>>>> >>>>>>>> I could make the Emacs mode use the same file, so that th ehistory >>>>>>>> is shared between emacs and non-emacs sessions. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Elias >>>>>>>> >>>>>>>> >>>>>>>> On 2 July 2014 23:41, Blake McBride <blake1...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Juergen, >>>>>>>>> >>>>>>>>> If you have trouble reliably finding the home directory, how do >>>>>>>>> you find the preferences file? >>>>>>>>> >>>>>>>>> I would say to find the .apl.history file in the same way and >>>>>>>>> place you find the .gnu-apl directory. That would be consistent. >>>>>>>>> >>>>>>>>> The problem I am having is that since I use GNU APL from the >>>>>>>>> command line, every time I start GNU APL up, I first have to check the >>>>>>>>> directory I am in, otherwise I get a bunch of random .apl.history >>>>>>>>> files all >>>>>>>>> over the place. >>>>>>>>> >>>>>>>>> I understand that I can fix the problem in my preferences file, >>>>>>>>> but now I have to remember to potentially edit that file for each >>>>>>>>> user or >>>>>>>>> machine I am on to account for the different home directory. I don't >>>>>>>>> have >>>>>>>>> to do that with my .gnu-emacs file. >>>>>>>>> >>>>>>>>> Either way is fine. Just sharing my opinion. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Blake >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jul 2, 2014 at 9:52 AM, Juergen Sauermann < >>>>>>>>> juergen.sauerm...@t-online.de> wrote: >>>>>>>>> >>>>>>>>>> Hi Blake, >>>>>>>>>> >>>>>>>>>> yes. The problem with that is that it requires the presence of a >>>>>>>>>> home directory. >>>>>>>>>> >>>>>>>>>> There are use cases like scripting where the interpreter cannot >>>>>>>>>> figure where the >>>>>>>>>> home directory is located and my strategy is to depend on as few >>>>>>>>>> environment >>>>>>>>>> variables (like $HOME or $PWD) as possible. >>>>>>>>>> >>>>>>>>>> Note that ~ is a shell convention and not a file system property >>>>>>>>>> so that ~/.apl.history >>>>>>>>>> or $HOME/.apl.history may fail under certain circumstances. >>>>>>>>>> >>>>>>>>>> /// Jürgen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/02/2014 04:25 PM, Blake McBride wrote: >>>>>>>>>> >>>>>>>>>> Dear Juergen, >>>>>>>>>> >>>>>>>>>> Thanks. I can do that, but every other Linux program I have >>>>>>>>>> ever used, although it may allow me to specify a config file >>>>>>>>>> location as >>>>>>>>>> you do, the default is always in the home directory. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Blake >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 2, 2014 at 6:24 AM, Juergen Sauermann < >>>>>>>>>> juergen.sauerm...@t-online.de> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Blake, >>>>>>>>>>> >>>>>>>>>>> you can set the path in the preferences files: >>>>>>>>>>> >>>>>>>>>>> READLINE_HISTORY_PATH = /home/... >>>>>>>>>>> >>>>>>>>>>> /// Jürgen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07/01/2014 11:14 PM, Blake McBride wrote: >>>>>>>>>>> >>>>>>>>>>>> GNU APL creates a .apl.history in whatever directory APL is >>>>>>>>>>>> started up in. This is unlike all other system I've seen, and a >>>>>>>>>>>> problem >>>>>>>>>>>> when you don't start APL in the same directory each time. I think >>>>>>>>>>>> rather >>>>>>>>>>>> than .apl.history, the system should use ~/.apl.history >>>>>>>>>>>> In other words keep in the home directory. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> Blake >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
