PDA

View Full Version : .profile not working?




CMT
Oct 18, 2010, 01:33 PM
I created a .profile in my home directory with this line:

export PATH=.:$PATH:~/bin
alias h history

But it look that it has no effect. Any ideas on what can be blocking? (I'm new to working with the Bash Shell)

Thanks!



lee1210
Oct 18, 2010, 01:38 PM
1) I think .bash_profile is what you want.
2) Don't add . to your path.

-Lee

robbieduncan
Oct 18, 2010, 01:38 PM
When you say "it has no effect" what have you done? Have you created a new shell/terminal window? Changes to the .profile don't effect currently running shells.

CMT
Oct 18, 2010, 02:02 PM
1) I think .bash_profile is what you want.

I put the same lines in .bash_profile, and the PATH extension worked perfectly.

However, now I get this message:

-----------------------------------
-bash: alias: h: not found
-bash: alias: history: not found
-----------------------------------

2) Don't add . to your path.

Hmm, just curious, why not? I did that as a initial configuration as recommended in the book I'm reading. (Beginning Show Leopard Programming)

Have you created a new shell/terminal window? Changes to the .profile don't effect currently running shells.

Of course, I know that.

Thanks!

robbieduncan
Oct 18, 2010, 02:04 PM
Try

alias h=history

CMT
Oct 18, 2010, 02:06 PM
Try

alias h=history


So we have a typo in the Book!

Thanks a lot, worked perfectly.

robbieduncan
Oct 18, 2010, 02:07 PM
So we have a typo in the Book!

Thanks a lot, worked perfectly.

Or it assumes a different shell where the syntax given works?

chown33
Oct 18, 2010, 02:08 PM
Have you checked for a website associated with the book, for any corrections to printed errors?

CMT
Oct 18, 2010, 02:14 PM
Or it assumes a different shell where the syntax given works?

Probably not. The book was made to work with the standard bash shell… (this is all I now until now, I'll continue reading)

Have you checked for a website associated with the book, for any corrections to printed errors?

I'll check that. The book is quite recent. It cover a lot of things in more than 600 pages. So I think it's natural that an errata starts to appear.

Thank you.

lee1210
Oct 18, 2010, 02:21 PM
While OS X is generally a "single-user" system, having . in your PATH in any UNIX is considered risky, because someone could place a dangerous executable named something like ls in some random directory on the system. Once you cd into that directory, when you do an ls to take a look maybe your home directory is going to be wiped out, etc. In the case of OS X there's probably not a "someone" that would do this like they might on a multi-user UNIX, but it's just "best practice". Typing ./ before commands isn't too hard, and you're likely going to be hitting up arrow to get to the command in your history more often than manually typing it.

It's a bit disappointing that this recommendation would be published. Hopefully no one breaks into your system, but if they got in via some under-privileged account, but dropped an executable somewhere that you (using a privileged account) might run then a pretty low-impact exploit becomes much more dangerous.

-Lee

CMT
Oct 18, 2010, 02:30 PM
While OS X is generally a "single-user" system, having . in your PATH in any UNIX is considered risky, because someone could place a dangerous executable named something like ls in some random directory on the system. Once you cd into that directory, when you do an ls to take a look maybe your home directory is going to be wiped out, etc. In the case of OS X there's probably not a "someone" that would do this like they might on a multi-user UNIX, but it's just "best practice". Typing ./ before commands isn't too hard, and you're likely going to be hitting up arrow to get to the command in your history more often than manually typing it.

It's a bit disappointing that this recommendation would be published. Hopefully no one breaks into your system, but if they got in via some under-privileged account, but dropped an executable somewhere that you (using a privileged account) might run then a pretty low-impact exploit becomes much more dangerous.

-Lee

Thanks Lee for the recommendation, clarified a lot.

Right at this moment I could discover why .profile didn't worked initially:

From this Unix FAQ http://hayne.net/MacDev/Notes/unixFAQ.html#shellStartup

Bash Startup Files
When a "login shell" starts up, it reads the file "/etc/profile" and then "~/.bash_profile" or "~/.bash_login" or "~/.profile" (whichever one exists - it only reads one of these, checking for them in the order mentioned).

After running a ls -A, I discovered there was indeed a file in my home directory named .bash_login. It contained only one line, adding php directory to the PATH.

So, it was blocking to read .profile. Once I added .bash_profile, this last one was chose to be read.

To make everything work as expected, I just added the same line in .bash_login to .profile and deleted that file.

Thank you a lot for the help.