Hi,

I am trying to implement a script which searches for lines with specific patterns from a source file and writes them to a new file.
I have over 40k lines that I need to search – which is tiresome to put onto the command line. Hence I listed them all in a file and passed that as an argument using the "grep -f" command.

This worked perfectly fine in the command line, but when i ran this inside a script it gives me "Permission Denied" error on the source data file.

Script is below:

#!/bin/bash

INFILE=$1
OUTDIR=$2

FILE=`basename "$INFILE"`

Path='/home/test'

grep -f "$Path/lines.txt" "$INFILE" > "$OUTDIR/$FILE"

[ $? = 1 ] && exit 1

exit 0

Error:
[/home/test]$ sh line_filter.sh Data_Feed.csv /home/test/output
line_filter.sh: line 10: Data_Feed.csv: Permission denied

Please advice what am i doing wrong here.

You may want to try adding -F to your grep. Also I would not use Path as a variable name. Are you sure basename is acting like you think it should? You may want to echo out what it is giving you.

First, the variable Path gets set but is never used in the script. (not the cause of the error)

The "permission denied" error could be due to any of:

1. File /home/test/output/Data_Feed.csv already exists, and you don't have write permission for it,
2. You lack write permission in directory /home/test/output,
3. You lack execute permission in /home/test/output or in one or more of its parent directories.

Directory /home/test would normally be the login directory for username "test". I trust that is what you intended.

1 members found this post helpful.

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 instead.

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" 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:

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.

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.