Error While executing the shell script
 

While I am executing the below line in the shell script I am getting this error,


cd /home/users/test/scripts/ && . test ORACLE18C

/home/users/test/scripts/Rman_Backup_Archi.sh: line 9: .: test: file not found

Post the script in CODE blocks https://www.linuxquestions.org/quest...do=bbcode#code

dot space test says "source the file named test in the directory you're in" Not sure what happens with the ORACLE18C string...

Is there a file named test in /home/users/test/scripts/ ? (apparently not)

Here test is a shell script designed for setting environment variables like bash script .

And there’s an error in it? See #2, please.

Based on the error, the file test is not in the directory /home/users/scripts.

There are a couple of other issues. Such as whether or not test is a shell script file, it will need to be. It will need to be executable, and it will need a shebang term at the start of it. My parser will not accept a file with an improper extension, using that form of shell execution. Meanwhile if I use the more normal shell notation to run something, it will accept a file with no extension. That file does need to be a proper shell script file.

So, you need to post more details about things here. As others have said, use code tags because they preserve the spacing and formatting of the code. If you need assistance with that, there are guides in the LQ Site FAQ, or just use the advanced editor when you post and the # tool will make selected text into a code block.

Advice here is that providing brief, one line, not-detailed follow-ups are no further help to people. If you wish to maintain privacy of your code, then post representative examples of it.

Sorry to contradict you, but neither is true for a "sourced" script. As it will be executed BY the current shell anyway, a "shebang" will be ignored.
It doesn't need to have executable rights either, the shell will run it in either case.

Yes, probably, and won't argue your points. I've got bash, but it may not be a current bash. Mine shows 4.4 built back in 2016 and happens to presently be running via cygwin.

I played a bit on my shell and given the notation of DOT SPACE <script>, I could only source something which allowed execute permissions. I turned it on and off and found what I found. Meanwhile it also would not accept anything without a .sh extension.

Now if I used DOT SLASH <script> things worked far better. I still needed it to have execute permissions.

I would agree with you that the intentions of the shell should allow any file which contains shell commands to be sourced, but on my install, I only found what I found. All empirical, and not something I'm invested in disagreement about. There are those who have far more expertise with the shell than I.

What parser is that? For bash, neither executable permission nor the shebang is needed.

Sorry, not parser, shell.

Says it's bash 4.4 circa 2016, but presently running in cygwin.

I just goes by what I typed, what worked, and didn't.

As do I.

bash 4.3.30(1) in Debian 8
bash 4.1.2(2) in CentOS 6
bash 4.4.23(1) in Fedora 29

None of those require either execute permission or a shebang line in a file being sourced.

Neither did bash 4.2.053 on Slackware (I tested it before I posted my previous response, just forgot to say so).

Source will not look in the current directory for its file if the script is in POSIX mode.

https://www.gnu.org/software/bash/ma...OSIX-Mode.html