|
Home > Archive > Unix Programming > June 2005 > How to determine path of executable?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to determine path of executable?
|
|
| Torsten Mueller 2005-06-14, 7:53 am |
| HPUX, aCC (HP ANSI C++ B3910B A.03.27)
I have to determine the path of an executable. I want the same value
as argv[0]. The problem is - my code is a library. I cannot use
argv[0]. I want to use my code in a shared library and (statically
linked) in an executable. Is there a way to determine this path?
Thanks
T.M.
| |
| Måns Rullgård 2005-06-14, 7:53 am |
| Torsten Mueller <dev-null@shared-files.de> writes:
> HPUX, aCC (HP ANSI C++ B3910B A.03.27)
>
> I have to determine the path of an executable. I want the same value
> as argv[0]. The problem is - my code is a library. I cannot use
> argv[0]. I want to use my code in a shared library and (statically
> linked) in an executable. Is there a way to determine this path?
In general, no. Why do you need this information?
--
Måns Rullgård
mru@inprovide.com
| |
| Lew Pitcher 2005-06-14, 5:56 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Torsten Mueller wrote:
> HPUX, aCC (HP ANSI C++ B3910B A.03.27)
>
> I have to determine the path of an executable.
Why? In my experience, when someone says that they have to determine the
path of an executable, they are trying to solve the wrong problem.
Perhaps we can help you solve the right problem.
> I want the same value
> as argv[0].
Which isn't guaranteed to be a path, let alone "the path to the executable".
> The problem is - my code is a library. I cannot use
> argv[0].
And you wouldn't want to, even if you could.
>I want to use my code in a shared library and (statically
> linked) in an executable. Is there a way to determine this path?
Short answer: No, there is no way to determine the path to the executable.
Long answer: Yes, there are several, implementation specific, ways to do
this, but none are guaranteed to be accurate or correct during the
execution lifetime of the process.
- --
Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFCrtaAagVFX4UWr64RAmv9AJ443JwhXW+j
qu1/yUIfSfdNZPkcEgCfaiJB
kPxfh22evmipG4i7VpjcPlA=
=YKwc
-----END PGP SIGNATURE-----
| |
| Torsten Mueller 2005-06-14, 5:56 pm |
| Lew Pitcher <Lew.Pitcher@td.com> schrieb:
>
> Why?
(This question seems to be always the first question ...)
> In my experience, when someone says that they have to determine the
> path of an executable, they are trying to solve the wrong problem.
> Perhaps we can help you solve the right problem.
Yeah, it's just to implement the same algorithm that is used under
Windows. I port a software component and it has a config file located
near the executable.
By the while I read somewhere UNIX programmers should use just a fixed
path for config files of an application, /var/opt/PACKAGE or
/usr/local/etc or something like this. I can do this and this would
indeed be a simple solution for the problem. But it's different than
under Windows and then I have to manage such differences. Other people
must know them to avoid confusion.
OK, thanks.
T.M.
| |
| Pascal Bourguignon 2005-06-14, 5:56 pm |
| Torsten Mueller <dev-null@shared-files.de> writes:
> Lew Pitcher <Lew.Pitcher@td.com> schrieb:
>
>
> (This question seems to be always the first question ...)
>
>
> Yeah, it's just to implement the same algorithm that is used under
> Windows. I port a software component and it has a config file located
> near the executable.
Right, that is the wrong problem.
On unix, there may be several users running the same program, and they
won't have all the access rights to read/write the configuration file.
So you should put configuration files in the current user home
directory (or if it's a system-wide tool like a server daemon, in /etc).
#define PNAME "MyProgram"
char* conf_path=concatenate(getenv("HOME"),"/.",PNAME,".conf",0);
If you will you can either have a #include directive in
~/.MyProgram.conf that would allow each user to include at will a
common configuration file (eg. /etc/MyProgram.defaults), or you can
process the two files:
#define PREFIX "" /* could be "/usr/local" */
#define PNAME "MyProgram"
char* global_conf_path=concatenate(PREFIX,"/etc/",PNAME,".conf",0);
char* user_conf_path=concatenate(getenv("HOME"),"/.",PNAME,".conf",0);
> By the while I read somewhere UNIX programmers should use just a fixed
> path for config files of an application, /var/opt/PACKAGE or
> /usr/local/etc or something like this. I can do this and this would
> indeed be a simple solution for the problem. But it's different than
> under Windows and then I have to manage such differences. Other people
> must know them to avoid confusion.
Windows users are rarely unix users, so it won't confuse them to put
configuration files in /etc or in $HOME. On the other hand, it would
confuse unix administrators and unix user a lot if you did not put
them in /etc or in $HOME.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
| |
| Gordon Burditt 2005-06-14, 5:56 pm |
| >I have to determine the path of an executable. I want the same value
>as argv[0].
You do know that the value of argv[0] can have absolutely NOTHING
to do with the path to an executable, right? And if there's any
advantage to be gained by making your program find the WRONG
executable, someone WILL invoke it that way maliciously.
>The problem is - my code is a library. I cannot use
>argv[0]. I want to use my code in a shared library and (statically
>linked) in an executable. Is there a way to determine this path?
What were you planning on using this value for? Nothing besides
error messages, I hope. It doesn't sound very secure.
Gordon L. Burditt
| |
| Lew Pitcher 2005-06-14, 5:56 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pascal Bourguignon wrote:
> Torsten Mueller <dev-null@shared-files.de> writes:
>
>
>
>
> Right, that is the wrong problem.
>
> On unix, there may be several users running the same program, and they
> won't have all the access rights to read/write the configuration file.
> So you should put configuration files in the current user home
> directory (or if it's a system-wide tool like a server daemon, in /etc).
To expand on that point a bit,
Per-user configuration should be stored in a file or directory in the
user's home directory
Systemwide configuration and/or configuration defaults, should be stored
in a file or directory in one of the standard configuration directories.
A user-invoked program should use the config file in the home directory,
and perhaps fill in the unspecified values from the system config file.
This might be implemented as
load system config file
load user config file, overriding values of system config file
or it might be implemented as
load user config file
load system config file, discarding values already set by user config
or, it might even be implemented as
if user config exists
load user config file
else
load system config file
fi
- --
Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFCrwOHagVFX4UWr64RArpLAKCifXg2l7M//+ZphywTouFCb1vlNACguuO7
UGNuRxwZHD6GkAhL4f7kzwE=
=qKLt
-----END PGP SIGNATURE-----
| |
| Lew Pitcher 2005-06-14, 5:56 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gordon Burditt wrote:
>
>
> You do know that the value of argv[0] can have absolutely NOTHING
> to do with the path to an executable, right?
Perhaps a demonstration for the OP would be in order....
First, a program that echos all it's arguments, including argv[0]
pitchl@srdscs05:~/code/argv0$ cat showargs.c
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
int count;
printf("%s Begins\n",__FILE__);
printf("argc == %d\n",argc);
for (count = 0; count < argc; ++count)
printf("argv[%d] == \"%s\"\n",count,argv[count]);
printf("%s Ends\n",__FILE__);
return EXIT_SUCCESS;
}
pitchl@srdscs05:~/code/argv0$ cc -o showargs showargs.c
pitchl@srdscs05:~/code/argv0$ showargs one two 3
showargs.c Begins
argc == 4
argv[0] == "showargs"
argv[1] == "one"
argv[2] == "two"
argv[3] == "3"
showargs.c Ends
As you see, showargs echo's all it's arguments, including argv[0]
Now, let's use exec(3) to run showargs for us.
pitchl@srdscs05:~/code/argv0$ cat arg0.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
execl("./showargs",
"*&&%##/##@$@@\\... this is not my path at all :-( ",
"an argument",
NULL);
return EXIT_FAILURE;
}
pitchl@srdscs05:~/code/argv0$ cc -o arg0 arg0.c
pitchl@srdscs05:~/code/argv0$ arg0
showargs.c Begins
argc == 2
argv[0] == "*&&%##/##@$@@\... this is not my path at all :-( "
argv[1] == "an argument"
showargs.c Ends
As you can see, showargs ran, but argv[0] /was not/ the path to the
executable. In fact, argv[0] isn't a path to anything at all. And, this
is perfectly legal in a Unix system.
Now, lets try a variation. No argv[0] at all...
pitchl@srdscs05:~/code/argv0$ cat noargs.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
execl("./showargs",
NULL);
return EXIT_FAILURE;
}
pitchl@srdscs05:~/code/argv0$ cc -o noargs noargs.c
pitchl@srdscs05:~/code/argv0$ noargs
showargs.c Begins
argc == 0
showargs.c Ends
pitchl@srdscs05:~/code/argv0$
Here, showargs ran, but it didn't even get garbage as argv[0]. Instead,
it got nothing at all, no arg[0] whatsoever. Again, perfectly legal in
Unix, but bad breakage for a program that thinks that MSWindows rules apply.
- --
Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFCrwisagVFX4UWr64RAncqAKCaxtXPVUnz
5NZHa8uM1j21NrvNTQCg7Hq8
/h6V9p+SEne5KODio3nb39U=
=Oyii
-----END PGP SIGNATURE-----
| |
| Norman Black 2005-06-14, 5:57 pm |
|
"Torsten Mueller" <dev-null@shared-files.de> wrote in message
news:uoea9vwb2.fsf@fastmail.fm...
> Lew Pitcher <Lew.Pitcher@td.com> schrieb:
>
>
> (This question seems to be always the first question ...)
>
>
> Yeah, it's just to implement the same algorithm that is used under
> Windows. I port a software component and it has a config file located
> near the executable.
>
> By the while I read somewhere UNIX programmers should use just a fixed
> path for config files of an application, /var/opt/PACKAGE or
> /usr/local/etc or something like this. I can do this and this would
> indeed be a simple solution for the problem. But it's different than
> under Windows and then I have to manage such differences. Other people
> must know them to avoid confusion.
>
> OK, thanks.
>
> T.M.
Encapsulate the differences. I have "ConfigSettings" library code that
supports global and local settings. Local setting are per user. On Windows
the code uses the registry and uses current user for local and current
machine for global. On Unix systems the settings are saved in text files.
Local settings are in a hidden directory in the users home directory and
global settings are in /opt. The config settings take a company name as a
parameter. On Windows this is the registry directory and on unix a file
directory. For example the Unix global setting directory would be
/opt/Saperion. The Unix local directory would be $HOME/.Saperion/.
Norman
Saperion Inc.
| |
|
|
TJB replied to:
> In general, no. Why do you need this information?
I'm -shocked- that this answer is no.
In Windows land you would use this to figure where your installation
directory is. At start up I do something like this:
void layout_window_type::cd_to_self()
{
wchar_t buffer[ 16384 ];
GetModuleFileName( NULL, buffer, DIM(buffer) );
wchar_t *last_slash, *p;
last_slash = buffer;
p = buffer;
while (*p) {
p++;
if (*p == '\') {
last_slash = p;
}
}
if (*last_slash == '\') {
*last_slash = 0;
SetCurrentDirectory( buffer );
}
}
Then, I can hang configuration information off of the application's
directory So, regardless of the current directory of an application,
it can find its own root directory. Then, you can have configuration
stuff inside of that directory, and you don't need the registry any
more.
| |
| Rich Teer 2005-06-14, 5:57 pm |
| On Tue, 14 Jun 2005, stork wrote:
> I'm -shocked- that this answer is no.
Welcopme to proper programming!
> In Windows land you would use this to figure where your installation
> directory is. At start up I do something like this:
UNIX is not Windoze (thankfully).
> Then, I can hang configuration information off of the application's
> directory So, regardless of the current directory of an application,
> it can find its own root directory. Then, you can have configuration
> stuff inside of that directory, and you don't need the registry any
> more.
UNIX doesn't have a registry. And its designed to be multiuser from
the outset.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| SM Ryan 2005-06-14, 8:52 pm |
| Rich Teer <rich.teer@rite-group.com> wrote:
# On Tue, 14 Jun 2005, stork wrote:
#
# > I'm -shocked- that this answer is no.
#
# Welcopme to proper programming!
Most programs that do execs pass in an argv[0] that allows the executable
path to be guessed (it's either a path with at least one '/' or a file in
a $PATH directory). I would consider anything else to be poor programming
unless there's a specific, special protocol.
# > In Windows land you would use this to figure where your installation
# > directory is. At start up I do something like this:
#
# UNIX is not Windoze (thankfully).
#
# > Then, I can hang configuration information off of the application's
# > directory So, regardless of the current directory of an application,
# > it can find its own root directory. Then, you can have configuration
# > stuff inside of that directory, and you don't need the registry any
# > more.
#
# UNIX doesn't have a registry. And its designed to be multiuser from
# the outset.
It has poor way of doing it. MacOSX encourages programs and libraries to
be distributed as packages; it masquerades as a simple file, but in fact
it's a directory with all of its resource files and libraries and everything
else packaged together. As a consequence users can install programs by
dragging them from the CD to the disk drive.
A similar install on other Unices typically involves installing libraries
in /usr/lib or /usr/local/lib or /opt/lib, and support programs in
/usr/bin or /usr/local/bin or /opt/bin, and other data files god only knows
where so that you typically require root privileges to scatter the files
hither and thither around the disk. One result is a /usr/lib with hundreds
of files that nobody knows what purpose they serve, and whether they can
be safely deleted.
So which one is really better at handling multiple users? The one that
depends on giving everyone the root password or piles up users waitiing
for the admiinistrator to do installs? Or one that has executables
determine their executable path and finding its resources relative
to that path?
--
SM Ryan http://www.rawbw.com/~wyrmwif/
GERBILS
GERBILS
GERBILS
| |
| Torsten Mueller 2005-06-15, 2:49 am |
| Lew Pitcher <Lew.Pitcher@td.com> schrieb:
> argv[0] == "showargs"
> argv[0] == "*&&%##/##@$@@\... this is not my path at all :-( "
Sure. I know this. It depends on several conditions and on the OS
itself. In Windows it's always the same value containing an absolute
path.
T.M.
| |
| Måns Rullgård 2005-06-15, 2:49 am |
| SM Ryan <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
> Rich Teer <rich.teer@rite-group.com> wrote:
> # On Tue, 14 Jun 2005, stork wrote:
> #
> # > I'm -shocked- that this answer is no.
> #
> # Welcopme to proper programming!
>
> Most programs that do execs pass in an argv[0] that allows the executable
> path to be guessed (it's either a path with at least one '/' or a file in
> a $PATH directory). I would consider anything else to be poor programming
> unless there's a specific, special protocol.
There was a very good demonstration of why you should not rely on this
posted in this thread by someone else.
> # > In Windows land you would use this to figure where your installation
> # > directory is. At start up I do something like this:
> #
> # UNIX is not Windoze (thankfully).
> #
> # > Then, I can hang configuration information off of the application's
> # > directory So, regardless of the current directory of an application,
> # > it can find its own root directory. Then, you can have configuration
> # > stuff inside of that directory, and you don't need the registry any
> # > more.
> #
> # UNIX doesn't have a registry. And its designed to be multiuser from
> # the outset.
>
> It has poor way of doing it. MacOSX encourages programs and libraries to
> be distributed as packages; it masquerades as a simple file, but in fact
> it's a directory with all of its resource files and libraries and everything
> else packaged together. As a consequence users can install programs by
> dragging them from the CD to the disk drive.
I don't want files or directories masquerading as anything else. I
want to know what I've got. If I need to move some files around as a
single unit, I use tar.
> A similar install on other Unices typically involves installing libraries
> in /usr/lib or /usr/local/lib or /opt/lib, and support programs in
> /usr/bin or /usr/local/bin or /opt/bin, and other data files god only knows
> where so that you typically require root privileges to scatter the files
> hither and thither around the disk. One result is a /usr/lib with hundreds
> of files that nobody knows what purpose they serve, and whether they can
> be safely deleted.
Keeping track of which files come from where is the job of a package
manager. All decent systems have one.
> So which one is really better at handling multiple users? The one that
> depends on giving everyone the root password or piles up users waitiing
> for the admiinistrator to do installs? Or one that has executables
> determine their executable path and finding its resources relative
> to that path?
I have yet to see a program that requires any special permissions to
be installed. Most programs install without a glitch in any users'
home directory, and those that have glitches are usually trivial to
fix.
--
Måns Rullgård
mru@inprovide.com
| |
| Måns Rullgård 2005-06-15, 7:48 am |
| Torsten Mueller <dev-null@shared-files.de> writes:
> Lew Pitcher <Lew.Pitcher@td.com> schrieb:
>
>
> Sure. I know this. It depends on several conditions and on the OS
> itself.
It has nothing to do with OS. The OS just passes on whatever value
was given to the exec() call.
> In Windows it's always the same value containing an absolute path.
So let it be that way in Windows. Whatever OS you're writing for, you
have to play by the rules it sets. One of the rules in Unix is that
argv[0] can be anything or nothing.
--
Måns Rullgård
mru@inprovide.com
| |
| Lew Pitcher 2005-06-15, 7:48 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Torsten Mueller wrote:
> Lew Pitcher <Lew.Pitcher@td.com> schrieb:
>
>
>
>
> Sure. I know this. It depends on several conditions and on the OS
> itself. In Windows it's always the same value containing an absolute
> path.
P'haps an analogy will help.
I live in Canada, where we drive on the right side of the road.
I want to move to Britain, where they drive on the left side of the
road. However, I /insist/ that I always be permitted to drive on the
right side of the road in Britain, because the side of the road that
traffic drives on depends on several conditions, and in Canada, those
conditions lead to driving on the right side. Since I can do it in
Canada, I should be able to do it in Britain.
Now, tell me what the consequences of my decision (and my disregard for
the traffic laws of Britain) will be.
By analogy, something that works in Windows is not guaranteed to work
/anywhere else/. And, when you are using Unix, you are using Unix, not
Microsoft Windows. Different rules of the road apply, and you have to
change your plans accordingly.
My little demo just shows that there /are/ different road rules between
Unix and Windows, and /why/ you should be mindfull of them.
- --
Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFCsCSOagVFX4UWr64RAsgmAJ9s56RpMGtA
wEuIjZXwxXZU4trFhwCfcjQL
IS/lin7ocVnR9cRTLqbxJcE=
=7XMv
-----END PGP SIGNATURE-----
| |
| Markus Becker 2005-06-15, 6:10 pm |
| Lew Pitcher <Lew.Pitcher@td.com> schrieb:
> I live in Canada, where we drive on the right side of the road.
>
> I want to move to Britain, where they drive on the left side of the
s/left/wrong/ ;-)
> By analogy, something that works in Windows is not guaranteed to work
> /anywhere else/. And, when you are using Unix, you are using Unix, not
Most of the time, something that works in Windows is even guaranteed
not to work anywhere else.
Markus
| |
| SM Ryan 2005-06-15, 6:10 pm |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@inprovide.com> wrote:
# SM Ryan <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
#
# > Rich Teer <rich.teer@rite-group.com> wrote:
# > # On Tue, 14 Jun 2005, stork wrote:
# > #
# > # > I'm -shocked- that this answer is no.
# > #
# > # Welcopme to proper programming!
# >
# > Most programs that do execs pass in an argv[0] that allows the executable
# > path to be guessed (it's either a path with at least one '/' or a file in
# > a $PATH directory). I would consider anything else to be poor programming
# > unless there's a specific, special protocol.
#
# There was a very good demonstration of why you should not rely on this
# posted in this thread by someone else.
Nor is there any guarentee a process starts with fd 0 open readable and fd 1
and 2 open writable. That's a shell convention, not a kernel requirement.
But, again, unless you have specific reason not do so, it would be bad
programming to exec otherwise.
# I don't want files or directories masquerading as anything else. I
# want to know what I've got. If I need to move some files around as a
# single unit, I use tar.
Do an ls of /usr/lib and identify what each library is used for. Or if it used
for anything.
# I have yet to see a program that requires any special permissions to
I've seen few programs that don't want to be installed in /usr or /usr/local
or /opt.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
If you plan to shoplift, let us know.
Thanks
| |
| Pascal Bourguignon 2005-06-15, 6:10 pm |
| "stork" <tbandrow@mightyware.com> writes:
> TJB replied to:
>
>
> I'm -shocked- that this answer is no.
>
> In Windows land you would use this to figure where your installation
> directory is. At start up I do something like this:
[...{blah blah blah ... more windows code}...] ;-)
If you need to locate the installation directory, you can easily do it
in unix:
----(install-script)----------------------------------------------------
#!/bin/bash
# installation script
TARBALL="$1"
installdir="$2"
[ -z "$installdir" ] && read -p 'Where do you want to install?' installdir
mkdir -p "$installdir"
tar -C "$installdir" -zxf "$TARBALL"
sed -e "s/installdir/$installdir/g" > "$installdir/pgm" <<EOF
#!/bin/bash
export RESOURCES="installdir"
exec "$RESOURCES/bin/pgm" "$@"
EOF
chmod 755 "$installdir/pgm"
------------------------------------------------------------------------
Now, you install your program pgm with:
./install-script pgm.tar.gz /opt/pgm
and instead of launching the program with: /opt/pgm/bin/pgm, you
launch it with /opt/pgm/pgm
Since most probably you'll have other installation specific stuff to
do, configure and pass to the program, these trampoline scripts are
quite useful.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
| |
| Lew Pitcher 2005-06-15, 8:59 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
SM Ryan wrote:
> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@inprovide.com> wrote:
[snip]
> # > Most programs that do execs pass in an argv[0] that allows the executable
> # > path to be guessed (it's either a path with at least one '/' or a file in
> # > a $PATH directory). I would consider anything else to be poor programming
> # > unless there's a specific, special protocol.
> #
> # There was a very good demonstration of why you should not rely on this
> # posted in this thread by someone else.
>
> Nor is there any guarentee a process starts with fd 0 open readable and fd 1
> and 2 open writable. That's a shell convention, not a kernel requirement.
fd 0,1, and 2 are easily opened by the program if they are closed.
OTOH, argv[0] isn't recreatable by the program if it isn't supplied.
> But, again, unless you have specific reason not do so, it would be bad
> programming to exec otherwise.
Not "bad programming" per se. Just "unusual programming". Especially
considering that neither POSIX nor SUS nor even the C standard guarantee that
argv[0] will be a "path to the program". IIRC, the closest to that is the C
standard that argv[0], /if supplied/ will identify the program.
[snip]
- --
Lew Pitcher
Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCsL/ kagVFX4UWr64RAnoSAKCSw+wEBOuJmVx7eYSbP7X
Mk+JKBQCfcBnc
c/Ap1jiKgmjR+3t3XN0jrtw=
=R+oK
-----END PGP SIGNATURE-----
| |
| David Schwartz 2005-06-16, 2:49 am |
|
"SM Ryan" <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> wrote in
message news:11auu56li9o0j3d@corp.supernews.com...
> So which one is really better at handling multiple users? The one that
> depends on giving everyone the root password or piles up users waitiing
> for the admiinistrator to do installs? Or one that has executables
> determine their executable path and finding its resources relative
> to that path?
If the program finds its resources relative to the path, that means the
program cannot be installed once for the system and the other files
installed by each user the way they want. The system that permits this
option is superior.
The typical way things are done in Windows is technically inferior to
the way they're typically done on UNIX because the UNIX way more easily
supports separate configuration files for each user with a single program
install. However, nothing forces you to do things on Windows the Windows
way.
The reasons for this are more historical than technical. The Windows way
originated on an operating system that was primarily used by a single user.
It became logical to associate configuration with a program rather than a
user. The UNIX way originated on systems where programs were typically
installed by administrators and used and configured by users. So it became
logical to disassociate program storage from data storage that could be
modified by program use.
You can, if you really want to, force either OS to use the other method.
Nothing in either OS forces one mechanism or the other. Trampoline scripts
are commonly used by programs that have a Windows heritage that have been
ported to Linux. An installer simply creates wrapper executable that pass
configuration information to the main executable. Each user can have their
own wrappers and a master executable can create the wrappers for each user
on request. This is a good compromise on UNIX.
I want to include a brief chunk of my usual Windows/UNIX rant. You can
google for more detailed versions of this rant if you want. A lot of Windows
software sucks because UNIX programmers had to write code for Windows and
didn't bother to learn the Windows way. They did things the UNIX way on
Windows and produced a lot of really crappy software.
You are trying to do this in reverse. You are moving from Windows to
UNIX and are trying to make UNIX do what Windows does. Spend the time to
learn the UNIX way and the Windows way, and then in those few cases where
the Windows way really is better on UNIX or the UNIX way really is better on
Windows, you can even take advantage of that.
DS
| |
| Torsten Mueller 2005-06-16, 2:49 am |
| "David Schwartz" <davids@webmaster.com> schrieb:
> The typical way things are done in Windows is technically
> inferior to the way they're typically done on UNIX because the UNIX
> way more easily supports separate configuration files for each user
> with a single program install. However, nothing forces you to do
> things on Windows the Windows way.
>
> The reasons for this are more historical than technical. The
> Windows way originated on an operating system that was primarily
> used by a single user. It became logical to associate configuration
> with a program rather than a user. The UNIX way originated on
> systems where programs were typically installed by administrators
> and used and configured by users. So it became logical to
> disassociate program storage from data storage that could be
> modified by program use.
The multi user approach _can_ be relevant but _must_ not. Oftenly
applications do not have user specific configurations. Perhaps they
don't even have multiple users. Their configuration depends rather on
a system, a machine, a database, a web service or something else. If
there are users surely they have private configurations in their home
directories. But not in my case. I also don't want a very active
configuration, I want just a really small file that is written once
and used (read only!) for five or ten years one time a week.
In my case I find it just more complicated to leave my configuration
somewhere else than directly in the near of the executable. I work in
a large company. I have to apply for user rights on other directories
on about ten (!) different file systems located all over the country.
I have to inform several people - I'm just the developer - but there
are package builders/distributors/installers, integrators, testers,
administrators, supporters and users. And - this is interesting - none
of them and none of the other developers and also none of the
company's guide lines did make a clear suggestion for leaving config
files on a HPUX. So everybody solves this problem his own way (look at
the number of different answers in this and other threads). My way was
to do it the same way like under Windows.
T.M.
| |
| Måns Rullgård 2005-06-16, 7:52 am |
| SM Ryan <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
> # I don't want files or directories masquerading as anything else. I
> # want to know what I've got. If I need to move some files around as a
> # single unit, I use tar.
>
> Do an ls of /usr/lib and identify what each library is used for. Or
> if it used for anything.
Most of them I actually know what they do. For the rest I can ask the
package manager which package they belong to.
> # I have yet to see a program that requires any special permissions to
>
> I've seen few programs that don't want to be installed in /usr or
> /usr/local or /opt.
Don't want and refuse are not equivalent. All programs will have some
default installation location. If you don't like it, you can change
it. A program that really doesn't work if not installed in some
specific location is probably badly designed in other ways too, and is
rarely worth using.
--
Måns Rullgård
mru@inprovide.com
| |
| SM Ryan 2005-06-16, 7:52 am |
| "David Schwartz" <davids@webmaster.com> wrote:
#
# "SM Ryan" <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> wrote in
# message news:11auu56li9o0j3d@corp.supernews.com...
#
# > So which one is really better at handling multiple users? The one that
# > depends on giving everyone the root password or piles up users waitiing
# > for the admiinistrator to do installs? Or one that has executables
# > determine their executable path and finding its resources relative
# > to that path?
#
# If the program finds its resources relative to the path, that means the
# program cannot be installed once for the system and the other files
# installed by each user the way they want. The system that permits this
# option is superior.
NIH.
I have a couple of MacOSX applications I have to port to Linux. Since
they're Wish, the application code is immediately transported. The problem
is one uses three GIFs and the other uses an executable.
For MacOSX, it's simple. I compile the binary and leave in it
@executable_path/../Resources/bin. I leave the GIFs in
@executable_path/../Resources/. I'll also have a fat and lite version:
the fat version has the Tcl and Tk frameworks in
@executable_path/../SharedFrameworks, together with their own script
libraries. The installer will simply be a zip file that unpacks to the
..app package.
For the Linux version, I can give them the binary precompiled, but I'll
need an installer and figure out some place to put the images and binary.
Installing Tcl/Tk will be their problem. They'll have to decide somewhere
in their $PATH where to put the wish script.
And you're still telling me the Linux approach is superior? Scattering
files hither and thither instead of keeping them packaged in one
neat little bundle?
MacOSX like Linux already has a separate mechanism for per-user configuration
files. In Linux, you typically stick them in ~/.application. In MacOSX,
~/Library/Preferences/application or ~/Library/Application Support/application.
# The typical way things are done in Windows is technically inferior to
# the way they're typically done on UNIX because the UNIX way more easily
# supports separate configuration files for each user with a single program
# install. However, nothing forces you to do things on Windows the Windows
# way.
Locating per-user configuration files is independent of locating user
independent application resources. The former should be home directory relative,
the latter should be kept together for easy installing or deinstalling.
Typical large applications consist of a variety of read-only files. Typical
Unix requires scatterring those around the file system. For example on IRIX
to get custom file types and icons you have to modify the FTR which requires
root access. On MacOSX all the icons files and rules can be embedded in
the application package. Drag the application onto your disk (or run it
from a CD) et voila all your icons are there.
Per user configuration files are typically given user home directory relative
paths on MacOSX. On other Unices, some programs will consult a ~/.rc file
while others require all their configuration files in a /usr/local or elsewhere
that an average user can't write. At most the latter will only support
per-user configuration by requiring a bunch of exported variables in .profile.
# The reasons for this are more historical than technical. The Windows way
# originated on an operating system that was primarily used by a single user.
Unix originated where most of the programmers had root access and could
treat the entire file hierarchy as their private playground. When it
expanded to real multiuser environments, the basic assumptions were not
reconsiderred.
Instead of fixing thirty year old problems, people apologise for them
and pile more and more gilt on to hide the dirt.
# You are trying to do this in reverse. You are moving from Windows to
I don't do windows. I do IRIX and Linux and MacOSX.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.
| |
|
| It seems to me that the success of Unix rests mightily on how directory
structures are used and enforced. If you take any Linux or Solaris
installation, the directory tree is absolutely beautiful compared to
the wretched mess that is Win32. But, as someone who flirts with Unix
but has yet to seal the deal, that beautiful tree is daunting in that I
have no global way of understanding what all of those conventions are.
Is there somewhere out there a global map of Unix that just explains
what each of the directories is for and how the structure is organized?
| |
| Eric Sosman 2005-06-16, 5:52 pm |
|
Torsten Mueller wrote:
>
> The multi user approach _can_ be relevant but _must_ not. Oftenly
> applications do not have user specific configurations. Perhaps they
> don't even have multiple users. Their configuration depends rather on
> a system, a machine, a database, a web service or something else. If
> there are users surely they have private configurations in their home
> directories. But not in my case. I also don't want a very active
> configuration, I want just a really small file that is written once
> and used (read only!) for five or ten years one time a week.
Have you considered the case of machine-specific config
files for a program that resides on a network-mounted file
system shared by many machines? Even though there's only
one config file per system, there may be more than one per
program installation directory.
(Reasons for a shared repository of executables are not
hard to imagine. Indeed, the Mozilla executable I am using
to write this message does not reside on the machine where
I'm writing it, but on an NFS mount shared with several
thousand other systems. It would be rather horrible if all
those systems had to stick their own config files into the
same shared mount point ...)
--
Eric.Sosman@sun.com
| |
| Rich Teer 2005-06-16, 5:52 pm |
| On Thu, 16 Jun 2005, stork wrote:
> It seems to me that the success of Unix rests mightily on how directory
> structures are used and enforced. If you take any Linux or Solaris
> installation, the directory tree is absolutely beautiful compared to
> the wretched mess that is Win32. But, as someone who flirts with Unix
> but has yet to seal the deal, that beautiful tree is daunting in that I
> have no global way of understanding what all of those conventions are.
> Is there somewhere out there a global map of Unix that just explains
> what each of the directories is for and how the structure is organized?
On Solaris, type man filesystem .
HTH,
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| Lew Pitcher 2005-06-16, 8:50 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rich Teer wrote:
> On Thu, 16 Jun 2005, stork wrote:
>
>
>
>
> On Solaris, type man filesystem .
On Linux, type "man hier"
And, of course, read the "Linux Filesystem Hierarchy Standard"
http://www.pathname.com/fhs/
- --
Lew Pitcher
Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCsiIHagVFX4UWr64RAs6aAJoC90lHsaYQ
j4+KxEP0akxopcgzvgCfSykC
o3EoBdJEB7Uh2EfLhFzd9Jk=
=gMOx
-----END PGP SIGNATURE-----
| |
| SM Ryan 2005-06-17, 2:52 am |
| # > On Solaris, type man filesystem .
#
# On Linux, type "man hier"
#
# And, of course, read the "Linux Filesystem Hierarchy Standard"
# http://www.pathname.com/fhs/
There's also the issue of revisionism. /usr is /user without the 'e'.
Like umount instead of unmount (one extra letter). Originally all home
directories were under /usr. Revisionists want usr to be some kind of
acronym and don't realise that used to be the /home directory.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
I'm not even supposed to be here today.
| |
| Lew Pitcher 2005-06-17, 7:58 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
SM Ryan wrote:
> # > On Solaris, type man filesystem .
> #
> # On Linux, type "man hier"
> #
> # And, of course, read the "Linux Filesystem Hierarchy Standard"
> # http://www.pathname.com/fhs/
>
> There's also the issue of revisionism. /usr is /user without the 'e'.
> Like umount instead of unmount (one extra letter). Originally all home
> directories were under /usr. Revisionists want usr to be some kind of
> acronym and don't realise that used to be the /home directory.
Agreed. I've had to "disagree" with a number of pseudo-knowledgable
people who try to tell me that /usr 'stands for' _U_nix _S_ystem
_R_esources. In those cases, I point out that my Unix Version 5 manuals
make no mention of Unix System Resources, and explicitly state that /usr
holds "user" files, like each user's individual home directory.
I've never had to argue about umount/unmount, but I can see it
happening. I'm glad I have my Unix Version 5 manuals, and a copy of the
Kernighan & Pike "The Unix programming Environment". They both have been
excellent arbiters for rebutting revisionist statements.
- --
Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFCsriIagVFX4UWr64RApysAKDeW7+6R+48
PB6GIJP1J/caLmHtDACdHGVT
EQz7NUT9HBLJxn+rLt6+Auo=
=zE/G
-----END PGP SIGNATURE-----
| |
| Matthias Buelow 2005-06-18, 5:50 pm |
| SM Ryan <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
>There's also the issue of revisionism. /usr is /user without the 'e'.
>Like umount instead of unmount (one extra letter). Originally all home
>directories were under /usr. Revisionists want usr to be some kind of
>acronym and don't realise that used to be the /home directory.
Hehe. I've read (and heard) several funny explanations for "/etc" in
the past. Apparently, some people suspect TLAs behind everything. 
mkb.
| |
| David Schwartz 2005-06-24, 6:00 pm |
|
"Torsten Mueller" <dev-null@shared-files.de> wrote in message
news:uhdfyj0an.fsf@fastmail.fm...
> The multi user approach _can_ be relevant but _must_ not. Oftenly
> applications do not have user specific configurations.
Frankly, I can think of only very few realistic applications that don't
have user-specific configurations. Every Windows application with a
'preferences' option has user-specific configurations.
> Perhaps they don't even have multiple users.
In that case, a configuration file or directory found relative to the
home directory is perfect.
> My way was
> to do it the same way like under Windows.
Isn't it obvious that that's inappropriate on Unix? You're trying to
cram a square peg in a round hole.
DS
| |
| Gordon Burditt 2005-06-24, 6:00 pm |
| >> The typical way things are done in Windows is technically
Placing a writable configuration file in the same directory as
an executable makes it easier for viruses to do their job, as
generally that also requires permission to create files in the directory.
[vbcol=seagreen]
And many viruses.
[vbcol=seagreen]
>The multi user approach _can_ be relevant but _must_ not. Oftenly
Is this because of a contract to not make changes that
are incompatible with existing viruses?
Gordon L. Burditt
|
|
|
|
|