Wolfgang Rosenauer wrote:

On 2005-10-19 at 14:24:12 +0100, Francesco Scaglioni wrote (shortened):

...

Using 10. Ran apt, installed thunderbird. Errors out with :

"cannot find mozilla runtime directory"

Mozilla browser runs fine ( as doesw firefox ). Is this a bug or is it me ?

Never saw this before. What do you start exactly? You have to use /usr/bin/thunderbird to get it working properly.

CU,

Wolfgang

If you restart kde, you should find it at /Menu/Internet/E-Mail. Jim

* Francesco Scaglioni [10-24-05 09:58]:

I use windowmaker. Was previously able to issue command thunderbird and have it run. If I explicitly issue /usr/bin/thunderbird then it runs. The SuSE generated menu in wmaker for thunderbird doesn't run. Sounds like a paths bug somewhere.

Hummm, then why don't you edit/correct the menu to show the full path? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

Hi, On 2005-10-24 at 23:30:54 +0100, Francesco Scaglioni wrote (shortened):

,------ | > Hummm, then why don't you edit/correct the menu to show the | > full path? `------

As I tend to just open a dialogue for a command and then type ` thunderbird ` editing the menu would be a fudge. The underlying problem is no doubt far more interesting than the work-around solution ( that would also entail me using such things as trackpoints and mice etc [ that I would rather avoid ] ).

The information which command is finally executed is still not clear to me. If you get this via typing "thunderbird" in the commandline please tell us what is executed. You should be able to see this with "which thunderbird". CU, Wolfgang -- SUSE LINUX GmbH -o) Tel: +49-(0)911-740 53 0 Maxfeldstr. 5 /\\ Fax: +49-(0)911-740 53 679 90409 Nuernberg, Germany _\_v simply change to www.suse.com

Am Dienstag 25 Oktober 2005 09:49 schrieb Francesco Scaglioni :

... Seems as if ~/bin was being looked at prior to the shared bin.

Hi, on an old *nix system the order was /usr/(s)bin /usr/local/(s)bin. So you always end up with the commands the admin configured. On newer (Linux) systems the order changed: ~/bin /usr/local/bin /usr/bin to give programms that the user installed a chance. The old fashion is more secure and suitable for a multiuser (server) system, the newer fashion is really usefull for a single user (home user) system. -- mdc

Am Dienstag 25 Oktober 2005 12:42 schrieb Rasmus Plewe :

On Tue, Oct 25, 2005 at 12:02:20PM +0200, meister@netz00.com wrote:

...

Am Dienstag 25 Oktober 2005 09:49 schrieb Francesco Scaglioni :

...

... Seems as if ~/bin was being looked at prior to the shared bin. on an old *nix system the order was /usr/(s)bin /usr/local/(s)bin. So you always end up with the commands the admin configured. On newer (Linux) systems the order changed: ~/bin /usr/local/bin /usr/bin to give programms that the user installed a chance. The old fashion is more secure and suitable for a multiuser (server) system, the newer fashion is really usefull for a single user (home user) system.

Hi Rasmus,

I disagree. No user has to have write access to /usr/local. If users can write into any directory in the default path: shoot the admin.

yes, you are right. No ordinary user should be able to write to /usr/local.

Would you like to explain why you think it is more secure that /usr takes precedence over /usr/local[0]? This would make it very hard for the admin to 'replace' commands without altering the installed files.

Because so you always get the command, that came with the distributed os and not the 'replaced' one. If you place e.g. a more powerfull "grep" command in /usr/local/bin, thats fine for the commandline usage, but some os-distributed scripts may fail, because they relay on the "old style" command in /usr/bin. Thats a problem I ran in on an old SCO-Unix.

There is a lot of sense in having the order something like $HOME/bin;/urs/local/bin;/bin,

ACK

and there is no other risk than that a user might shoot himself (and not others) in the foot.

Here is /usr/local/bin a question. If you install a new "grep" in /usr/local/bin and your co-user installs some pice of software (as root (su)), the installer may fail, because of the wrong "grep" being used. Sure you can argue "the installer should provide it's own $PATH", but most of them just do a "which prog" or even nothing.

You might however argue about having $HOME/bin in there, I grant you that.

I _love_ ~/bin in front of my $PATH, to overwrite system commands for _my own_ user.

And *sbin* does not belong into a users PATH by default, IMHO.

On my own user, I often put it in, especially while testing new (SuSE-)distros. It's an easy way for lazy people :-)

[0] I tend to think that it always was /usr/local over /usr, in the history of Unix, but am not historian enough to be able to prove it.

On SCO 3.2 there is /bin;/usr/bin;/usr/local/bin BTW: The same arguments used here for bin apply also to lib IMHO. -- mdc