Is there a way to have a script called source, that can be run without the full path?

abefroman · 01-18-2015, 12:39 PM

Is there a way to have a script called source, that can be run without the full path?

Ex:
When I run:
export PATH=/home/user:$PATH
source

I get:

Code:

$ source
bash: source: filename argument required
source: usage: source filename [arguments]

However I want it to run my script called source:

Code:

$ cat source 
#!/bin/bash
echo "Hello World"

Is there way to override a shell builtin in the PATH var or some other way?

astrogeek · 01-18-2015, 12:45 PM

alias should do it.

abefroman · 01-18-2015, 12:53 PM

Quote:

Originally Posted by astrogeek

alias should do it.

Thanks! That worked:

Code:

$ alias source="~/source"
$ source
Hello World

But, how can I get that to carry over to a script though?

Ex.

Code:

$ ./source2
./source2: line 2: source: filename argument required
source: usage: source filename [arguments]
[biosadm@nickbios ~]$ cat source2
#!/bin/bash
source

astrogeek · 01-18-2015, 01:00 PM

Quote:

Originally Posted by abefroman

Thanks! That worked:

Code:

$ alias source="~/source"
$ source
Hello World

But, how can I get that to carry over to a script though?

Ex.

Code:

$ ./source2
./source2: line 2: source: filename argument required
source: usage: source filename [arguments]
[biosadm@nickbios ~]$ cat source2
#!/bin/bash
source

OK, if I understand you correctly, what you want is for the fake-souce to be be available to non-interactive shells (i.e. when running a script).

To do that you would need the alias to be set through the BASH_ENV variable.

From man bash:

Quote:

When bash is started non-interactively, to run a shell script, for example, it looks for the variable
BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the
name of a file to read and execute. Bash behaves as if the following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the filename.

urbanwks · 01-18-2015, 01:29 PM

if you mean that you want to run

Code:

source

instead of

Code:

/home/user/source

then you can put (or link) "source" in /bin or /usr/bin or /usr/local/bin. they should already be in your path.

or maybe i misunderstand.

astrogeek · 01-18-2015, 01:38 PM

Quote:

Originally Posted by urbanwks

if you mean that you want to run

Code:

source

instead of

Code:

/home/user/source

then you can put (or link) "source" in /bin or /usr/bin or /usr/local/bin. they should already be in your path.

or maybe i misunderstand.

For source, there is no binary on many/most systems, it is a bash built-in, which I think is the OPs point.

An alias can override a built-in, but then the alias must be set in the non-interactive shell context as well.

But I am curious - why override the built-in for source? It seems like a good way to break a system with unanticipated side effects!

And then what about ., should it act the same way or be different?

rknichols · 01-18-2015, 02:26 PM

By default, aliases are not expanded in non-interactive shells. You can use the shopt builtin command to set the expand_aliases option, but that puts your shell at the mercy of whatever aliases happen to have been set. Unless you are running in a tightly controlled environment, there would be no command you could trust unless you have carefully purged the BASH_ALIASES associative array of anything not wanted.

abefroman · 01-18-2015, 05:52 PM

Thanks for the info on this!