0

I am developing a shell script for ubuntu linux os. I am expecting the exit code to be always 0(success), but it returns 1(if no content in the file / non-matching pattern)

Code:

# set -xeo pipefail #commented this line, still exits at first grep
set +e

for file in ${files_folder}/*.csv
do
    matching_records=${base_path}/test/match.csv # Records present in local and source file
    only_source_records=${base_path}/test/source.csv # Records not in local and present in source file
    unique_user_ids=${base_path}/test/source_user_id.csv # user ids only from source file

    cut -d, -f4 ${file} > ${unique_user_ids} # Extract user ids only from source file
    grep -x -f ${unique_user_ids} ${base_path}/test/user_ids_to_delete.csv > ${matching_records}
    grep -v -f ${base_path}/test/user_ids_to_delete.csv ${unique_user_ids} > ${only_source_records}
done

In the above code the first grep itself fails, if any of ${unique_user_ids} and ${base_path}/test/user_ids_to_delete.csv file doesn't contain any content, but i want both the grep to always return success exit code

Edit: I tried setting set +e at the top of the file and commented out this line set -xeo pipefail which was there before at the start of file.

user8576367
  • 207
  • 3
  • 14
  • 3
    If the problem is that you are using `set -o errexit` (`set -e`) and the `grep` exit code is causing the program to stop, see [Bash ignoring error for a particular command](https://stackoverflow.com/q/11231937/4154375). Also see [BashFAQ/105 (Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?)](https://mywiki.wooledge.org/BashFAQ/105). – pjh Mar 16 '23 at 01:25
  • I don't see you evaluating the return code .. what's the actual issue? – tink Mar 16 '23 at 01:26
  • @tink execution of the script automatically getting stopped at the first grep – user8576367 Mar 16 '23 at 01:27
  • 2
    @user8576367, that stop-at-first-error behavior is the shell feature `set -e`. You **shouldn't use** `set -e`; it has deeply unintuitive, surprising behavior (that varies between shells and between versions of the same shell, so it's not even a consistent set of rules you can learn). Read BashFAQ #105, as linked above, particularly including the exercises; the comment by pjh is precisely on-point. If it was turned on before your code started execution (some "helpful" CI tools do this by default, f/e), you can turn it off yourself with `set +e`. – Charles Duffy Mar 16 '23 at 01:41
  • 1
    (To be clear, disabling `set -e` won't make the exit status stop being 1, but it _will_ stop the shell from exiting automatically as soon as that status is returned to it; if the last line of the script has a nonzero exit status and you want to prevent the script's overall exit status from being nonzero in turn, you can override that and tell the script to return a zero exit status by adding `exit 0` as the final line; or, as the linked duplicate suggests, you can put `||:` after the individual line whose exit status you want to ignore) – Charles Duffy Mar 16 '23 at 02:36
  • 1
    btw, there are some minor quoting issues here -- you might want to run your code through http://shellcheck.net/ and fix what it points out; otherwise, CSV files with spaces in their names will be trouble. – Charles Duffy Mar 16 '23 at 02:37
  • 1
    BTW, `set -o pipefail` is usually fine (there are caveats, see [bash: `zcat | head` causes pipefail?](https://stackoverflow.com/questions/41516177) for an example, but it's generally worth the trouble); and as long as you're prepared for its caveats, the same is often also true of `set -u` (which is the topic of [BashFAQ #112](https://mywiki.wooledge.org/BashFAQ/112)). It's really just `set -e` that gets the suspender-wearing greybeards riled up. :) – Charles Duffy Mar 16 '23 at 03:14
  • This is expected behaviour. Have a look at the grep man-page, where it describes the exit code. – user1934428 Mar 16 '23 at 08:37

0 Answers0