Page 1 of 1

SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 2:27 am
by hal
OS: WinXP32
SAb v. 0.4 RC5
Installed using Win zipped binaries

Every time I upgrade to a new version, I have to amend the following parameters in the config .ini file, so that they point to correct path/folders within the new installation dir:
log_dir
download_dir
complete_dir
nzb_backup_dir
cache_dir
dirscan_dir

I would be very grateful if sab could be changed to detect the path in which it is located, and store it as a variable, such as SAB_INSTALL_DIR.  Then the above configured paths would automatically reflect the installed dir, like:


%SAB_INSTALL_DIR%\logs


Hope this is possible.
Thanks
Hal

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 3:41 am
by shypike
If SABnzbd detects the file "sabnzbd.ini" in its program folder, it will automatically assume that the base for all relative paths is the program folder.

You can also specify a -f parameter, like:

Code: Select all

SABnzbd.exe -f d:\path\usernet\sabnzbd.ini
In this example, all relative paths will be relative to d:\path\usenet.

This is all documented in:
http://sabnzbd.wikidot.com/command-line-parameters
and
http://sabnzbd.wikidot.com/configure-directories (take note of footnote 1).

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 8:57 am
by hal
Hi Shypike

Thank you very much for your reply - I am glad that I have read some of the wiki since your post! ;-)

I feel that, while the two points you make are very helpful, they don't completely resolve my specific issue.

While the command line options are useful to know, using -f would still require me to amend its path during each upgrade.

Also, Sabnzbdgui automatically defaults to the sabnzbd.ini file in the user's home dir, rather than one in the sabnzbd program dir, and hence any relative paths are relative to the ini directory rather than the program directory.

I fully understand that the onus is really on the sabnzbdgui developer to resolve this, but surely the aim is to make sabnzbd easlier, more flexible and intuitive to use.  Having a variable (that could be explained in note in the ini file) would allow users to quickly solve these kinds of issues without taking up any of your user support time.

Rather than changing any existing config defaults, what I am suggesting is that the variable SAB_INSTALL_DIR simply be made available, so that people who edit the ini file directly will see it there (in a note) and realise that it is available to use if needed.

With thanks
Hal

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 10:08 am
by shypike
Third-party utilities should stay away from meddling with the INI file, it's undocumented for a reason.
They should use the documented API, and ask for more if it's not enough.

The only thing we are planning for a later release is to have SABnzbd write its host:port to the registry.
This should make it easier for utilities to contact SABnzbd.

As for your question.
I have a d:\usenet folder that contains the INI file and all folders are inside this one.
I can start ALL versions of SABnzbd with the same command.

Code: Select all

whatever-path\SABnzbd-f d:\usenet\sabnzbd.ini
If you don't specify an INI file at all, it will just create the required stuff in the user profile.
Perfectly re-usable between releases (except when we break queue-compatibility).

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 10:40 am
by hal
skypike

sabnzbd does not meddle with the ini file; it simply starts sabnzbd with no parameters, which defaults to using an ini file in the user's home dir.
Unfortunately, sabnzbdgui does not accept switches/parameters for starting sabnzbd, so configuring the location of the config file is not possible.

Your solution will not work, as all directories will default to subdirectories of d:\usenet or, otherwise, absolute paths must be configured which, as I have said, are not dynamic so must be changed for every upgrade.

The api cannot be used until sabnzbd has been started.  As I am using sabnzbdgui to start sabnzbd, using the api obviously is not an option.

I hope you can see that, contrary to me being pedantic, I honestly feel this would be a useful feature.

In your view, would this enhancement require a lot of extra work?

Thanks in advance
Hal

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 11:31 am
by shypike
When SABnzbd starts without parameters it looks for the file sabnzbd.ini file in the user's profile.
This is NOT dependent on where SABnzbd is installed.
You say:
so that they point to correct path/folders within the new installation dir:
Why do you want to have the folders in the program folder in the first place?
If you want that behaviour (compatible with the dinosaur-0.2.5 release) just stick the
sabnzbd.ini file in the program folder.

Just keep the INI file in the user profile and set full paths for all the folders in an independant place,
I don't see why you would ever want to change them.
Full paths are just that: full paths, not influenced at all by where SABnzbd lives.

Again, utilities have no business in the program folder.
Besides it is not possible for application to push back an environment variable to cmd.exe.
So what you ask cannot be done.

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 12:01 pm
by hal
shypike.
I understand that you have a different environment and requirements to me, and I think this is maybe why you are not able to visualise them.

The information that I am trying to convey to you is better explained in my last post rather than the first post.  To summarise my previous points:

1) sabnzbdgui does NOT use the sabnzbd.ini folder.  It simply starts sabnzbd WITHOUT parameters, (including NOT the -f parameter).  Hence sabnzbd will ALWAYS be started using an ini file in HOME.  When this happens, relative paths are not possible, as they are always relative to the config file path.  Obviously it is inadvisable to download and store large files to the system drive (where a user's HOME is typically stored) for fragmentation and free space issues
2) I don't want to use full paths, to ease the upgrade process

Hal

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 3:42 pm
by shypike
so that they point to correct path/folders within the new installation dir:
I still think that the upgrade process is best served by separating the program files
from the data.
You don't store your Word documents in c:\program files\Microsoft Office, do you?
Both in Windows and Unix people do their best to separate programs and data.

Even so, what's stopping you from placing the INI file in the program folder and just
overwrite the existing software with new software?
None of your data will be touched by this. And you get what you want: all paths are
relative to the program folder.

So: what you want is already possible. You just need to move your sabnzbd.ini file
from c:\documents and settings\USER\local settings\application data\sabnzbd\sabnzbd.ini
to the program folder.

Re: SAB_INSTALL_DIR Variable for ini file on Windows

Posted: July 2nd, 2008, 4:38 pm
by hal
Question:
shypike wrote: what's stopping you from placing the INI file in the program folder and just
overwrite the existing software with new software?
Answer:
hal wrote: 1) sabnzbdgui ... simply starts sabnzbd WITHOUT parameters, (including NOT the -f parameter).  Hence sabnzbd will ALWAYS be started using an ini file in HOME.  When this happens, relative paths are not possible, as they are always relative to the config file path. 
I appreciate, and totally agree with, your point about running executables securely on a read-only file system.  However, sab is one of the few programs that I *choose* to run differently on *my* system; I like the way that the sab package runs directly from its extracted folder and, with the enhancement that I have requested, I cannot think of a single way, off-hand, to make the software work any better for me.

I am not sure I completely understand the resistance to, what I feel is, a trivial enhancement, which simply adds a little flexibility to the way that sab can be configured.  If there is major dev work that would be required, then obviously I would concede and agree that it would not be sensible or feasible to add it.

Ultimately, I am very thankful for the product, and appreciate yours and your concomitants' efforts, so I will not labour the request any further.

Thank you for your responses to this thread.
Hal