Actually $FILE is being used as grep's output file name.
The external basename
command isn't needed though. You can use a built-in parameter substitution
Anyway, I agree with the above possibilities, as there's really nothing in the script itself that could be causing that kind of error. My best guess is that the user the script is running under is different from the one owning the file.
I also see another point of caution in the error message itself:
sh line_filter.sh Data_Feed.csv /home/test/output
" tells me that the interpreter being used isn't bash
, but the system's POSIX shell (which may indeed be bash
too, but in a more restricted form). This can only happen if the file is being executed like this:
$ sh line_filter.sh file.txt outdir
When done this way the shebang at the top of the file is ignored as a comment, and the /bin/sh
shell does the actual interpreting. When a script has a shebang configured for it, just execute it directly with the (relative or absolute) path preceding the name. It will then execute using that pre-configured interpreter.
$ ./scriptname.sh file.txt outdir
Not that it's really a problem in this case though, since all the syntax in the script is POSIX compliant anyway. But I suppose there's a possibility that the restricted access is related to it as well.
PS: Please use ***[code][/code]
*** tags around your code and data, to preserve the original formatting and to improve readability. Do not
use quote tags, bolding, colors, "start/end" lines, or other creative techniques. Thanks.