About /hone/<user_name>/.bashrc and /etc/bashrc

fanoflq · 03-09-2017, 07:14 PM

From Centos 7, home/<user_name>/.bashrc :

Code:

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

# User specific aliases and functions
~

I do not understand the bold faced lines above.
semantically it is like this:
If file /etc/bashrc exists,
then run this command:

Code:

. /etc/bashrc

Why is the dot AND a space before /etc/bashrc needed?

michaelk · 03-09-2017, 07:44 PM

The dot is the source operator. In a nutshell it runs the script within the current shell and any variables created or modified by the script will remain available after the script completes. In your example /etc/bashrc is the system wide global definitions and if the file exists will be loaded in addition to the user definitions in the local bashrc file.

Another example.
script1

Code:

#!/bin/bash
. myscript
echo $test

myscript

Code:

#!/bin/bash
test="Hello World"

Make script1 executable and see what happens when you run it.

fanoflq · 03-09-2017, 08:20 PM

Quote:

Originally Posted by michaelk

The dot is the source operator. In a nutshell it runs the script within the current shell and any variables created or modified by the script will remain available after the script completes. In your example /etc/bashrc is the system wide global definitions and if the file exists will be loaded in addition to the user definitions in the local bashrc file.
... ...

Thanks.
When I ran script1 like this: ./script1?
It works too.

BUT if I try this modification in script1, it fails:

Code:

#!/bin/bash
./myscript        #added a forward slash
echo $test

Code:

$ test=""                                                                                                 
$ echo $test

$ . script1
-bash: ./myscript: Permission denied

$ ./script1                                                                                               
./script1: line 2: ./myscript: Permission denied

Why do I get these error messages?
What is the difference between
"./<some_script1>" and ". <some_script1>" ?

Habitual · 03-09-2017, 08:27 PM

Code:

man test

explains regular file testing

. means current directory

fanoflq · 03-09-2017, 08:36 PM

Quote:

Originally Posted by Habitual

Code:

man test

explains regular file testing

. means current directory

Code:

Why do I get these error messages?
What is the difference between
"./<some_script1>" and ". <some_script1>" ?

michaelk · 03-09-2017, 08:38 PM

./myscript will execute the script and since the permissions do not allow it you see the error message.

As stated in your example the . means current working directory. If you set the permissions for myscript it will execute in a subshell but script1 will display an error because test is undefined.

Habitual · 03-09-2017, 08:41 PM

http://www.linuxquestions.org/questi...-paths-256350/

fanoflq · 03-09-2017, 08:55 PM

michaelk & Habitual :

What I am still not able to understand is that
when I ran ./myscript, I got a permission denied error.

myscript is residing in the same directory as script1.

Quote:

~/dir $ test=""
~/dir $ ./myscript #running myscript inside its directory
-bash: ./myscript: Permission denied
~/dir $ . myscript
~/dir $ echo $test
Hello World!

Here is better question.
Why do i have to "chmod +x myscript" when I ran it like this:

Code:

~/dir $ ./myscript     #running myscript inside its directory

while I do not have to "chmod +x myscript" for this command?

Code:

~/dir $ . myscript

chrism01 · 03-09-2017, 11:51 PM

Because each invocation of 'bash' creates a new shell (+env).
Sourcing via either of

Code:

. script.sh
# OR
source script.sh

includes the contents of script.sh into your (already running) current shell/env.
(obviously you'll need r perms)

This

Code:

./script.sh

means run the script in the curr dir ( this is what './' means in this context) if a) it has rx perms and b) rx perms match curr owner and/or group (& strictly speaking the curr partition must be mounted with exec option; see /etc/fstab)

As above, a new shell is a sub-shell (you should google that) and vars+values cannot be 'exported' upwards ie when that shell completes, any var/values created/set within the sub-shell will be wiped.

HTH

fanoflq · 03-10-2017, 02:53 AM

chrism01:

Thank you.
Below for future reference....

Quote:

# help .
#Notice the dot in front, i.e. help<space><dot>
#<dot> is a bash command when used like so.
.: . filename [arguments]
#Notice <dot><space><filename> [arguments]
Execute commands from a file in the current shell.

Read and execute commands from FILENAME in the current shell. The entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.

Exit Status:
Returns the status of the last command executed in FILENAME; fails if FILENAME cannot be read.

Likewise:

Quote:

# help source
#source is same as <dot> command See above.
source: source filename [arguments]
Execute commands from a file in the current shell.
... ...

./<filename> executes script in its own (sub)shell
and inherits from exported variables of current shell.
It does not do "reverse" exports of variables
back to the script that calls <filename> script.

BW-userx · 03-10-2017, 08:30 AM

this

Code:

. /etc/bashrc

and this

Code:

./script.sh

are two completely different things. You should have noticed you changed it. as one stated "The dot is the source operator" by adding a forwards slash to it changes its meaning. It is like a function call that you added an unqualified data type to its parameters . It will no longer give you the same desired results.

. (source or dot operator)