symlinks

Im not sure that you can do what you want to do.

If you link to the config directory then everyone has only one config file. The main one.

For the program to accept multiple config files that will have to be an option of the program.  Something along the line of a command-line option when the program is called such as

theprogram.exe -c ~/config

then just give each user their own script to call the program.

OR if the program can accept alternate directorys for config but doesnt recognize ~ give each user a script for

theprogram.exe -c ./config

where the period will specify the directory that the script is run from.

Ok, GP1628

Unfortunately the program doesn't have a command line option for the config directory - that would be nice and easy.

And I think freesource missed the idea a little. So I will try to clarify a little more.

The program requires a directory structure as follows.

program_dir/
     config

I would like to set it up such that config is a symlink to a config directory inside each and every users home.

ie

program_dir/
     config -> ~/config

so that if I run the program it picks up the config files from my home directory, and if the person sitting on my right runs the program it picks up the config files from his home directory. In this way there is no central config file - this is so that each user is able to have their own macros and setup and so forth without interfering what other people want to have set up.

Thats just it. links wont do that.

Unless the program itself is willing, I cant think of a way to do it.

Is the config path absolute? or is it relative? Does it look for the configs in a particular directory or one particular to the location that the program starts up in?

If there is no command line option.... is ther ean ini file which might inclucde the path structure that it is to use for its files? If installation wrote a line that the config resides in /myprog/config then removing the /myprog/ will often cause it to look in the directory its called in for the files.

Gandalf Parker

Hmmmm I thought about it some more. The problem with links is that its a command that allows many people to have access to one file, you kindof want it to work in reverse with one file being access to many peoples files.
This is purely a shot in the dark but I believe since its unix it should work.

If each person had a script which
 ln -s config /theprogram/conf
 theprogram

then it would create a new link each time they run it. Im not sure if it would overwrite the old link of the other user but if it did then this should work.
Since the program has already read the config and is already up and running it shouldnt be affected by the fact that the link changed.

You would have to test it to be sure.

Gandalf Parker

Exactly which program is this anyways?

I may have to try that Gandalf - although I don't expect it will work so nicely because the config files get written to by the program as well, I presume that it would require the link to be intact when it comes to do the write, otherwise I may be trying to overwrite someone elses config files.

With regards to what the program is it's a windows text editor by the name of MultiEdit.

Is there then an alternative to a link which may work in this way that I am unaware of ? (My unix knowledge isn't particularly large).

Yes, the way to do this would be to write a wrapper script.

Instead of running MultiEdit you would run the wrapper instead which would take care of finding the configuration file for whatever user runs the program.  There lot's of ways it could be written to do this.

Once way would be to simply copy over the configuration file to the only directory MultiEdit looks in, then execute MultiEdit, when MultiEdit finishes it will just remove the program.

Like this:

#!/usr/bin/perl

# By freesource
# Give it a name .. chmod 755 name.
# Put it in a Path
# Edit this to specifications, make sure
# the first bang line points to perl on
# your system . make sure you have perl
# or write something similiar in shell
# script.

$user_conf = $ENV{"HOME"} . "/config";

# copy user configuration file over
system "copy $user_conf /MultiEdit";

# run program
system "MultiEdit";

#clean out program directory
system "rm /MultiEdit/config";

   

Oh, and this line:

# copy user configuration file over
system "copy $user_conf /MultiEdit";

Should be this way instead

system "cp $user_conf /MultiEdit";

:)

.... so

#!/usr/bin/perl

# By freesource 1-8-2000
# Give it a name .. chmod 755 name.
# Put it in a Path
# Edit this to specifications, make sure
# the first bang line points to perl on
# your system . make sure you have perl
# or write something similiar in shell
# script.

$user_conf = $ENV{"HOME"} . "/config";

# copy user configuration file over
system "cp $user_conf /MultiEdit";

# run program
system "MultiEdit";

#clean out program directory
system "rm /MultiEdit/config";

Hmmm, there is a small problem with this.

Firstly the program is a Windows program so it actually gets run on the Windows boxes and the files are kept on the UNIX box.

The second problem is that the link to the config files is live and the files may change during a session - if a second user were to open up a session it may mess up the first user - or not let the second user overwrite the config files which may still be held open by the program.

You could use wine to run the program on the unix boxes, and a lock could be used.  It sounds like there will be many users using the program concurrently, but there are tricks to accomplish this.  Where can I find this program to try some experiments?

as GP1628 said, the only way might be a wrapper script which generates the symlink on the fly, but then you run into problems when more than on user accesses the program.

> Hmmm, there is a small problem with this.
> Firstly the program is a Windows program ..
NO, this is the only problem ;-)
Windows programs are designed for single-user, single-tasking, usually, so there is no need for multi-user support, IT'S WINDOZE. Dot.

If this stupid Windoze program cannot deal with multiple users, you may try to make a new installation for each user, therefore using it's own config directory for each user.

freesource - MultiEdit is made by a company call american cybernetics - I can't see a web address on it.

ahoffmann - yes I tend to agree with you that windows is the problem - but that is the environment I am working under (and personally I don't actually know enough about unix nor have the time to move myself to it now.

If no-one comes up with an answer that is easier for me I think I'll have to  give this one to Gandalf

when you say:

ln -s ~/config config
doesn't work because it replaces the ~ with my home dir path...

its worth trying to do
# su <username>
then
# ln -s ~/config config # orwathever you want
and then to get back to your user
# exit

Hopeing I understood your question...

paulqna,

when you do a ln -s ~/config config the command interpreter will interpret the ~ immediately as being the home directory of the current user, hence if I do that the link is to /usr/jaredc/config, when the next person comes along the link will still point into my home dir rather than theirs.

It is possible to escape the ~ character but then it is not interpreted when you use the link either.

What about putting the other way round. Instead of creating link
for the config file you create a links for all the files of the program.

You have a directory /home/program holding all the program files.
You have a directory /home/user1/program wit the config file
and links for all other files pointing to /home/program.
Depending on how your PC is getting at the files (NFS, samba)
you can not use symlinks, but neet to use 'normal' links. As
long as your fileas are in the same filesystem on the unix box
it will work the same.

Markus

Then

# ln -s ~/config config # orwathever you want.

Should be

# ln -s \~/config config # orwathever you want.

Paul

Sorry when i was reading your question i saw this was a really stupid one... ;(

Markus - This one is a good idea, and I am trying that as well, although unfortunately I think it may create other problems as well.

But certainly this is the closest anyone's come to an idea that may solve the problem so far.

still suggested to install it per user.
I'm also not shure if it is possible to use symlinks for the program files (instead of a new installation), 'cause of M$'s proprietary file-locking when using a program or a data file used by this program.
This needs to be tested extensively.