Scripts should not fail if it can't change group on files

[Nicklas Nordborg]

See #1174. This implemented a 'chgrp' command to allow external data to be shared to a specific group based on the prefix used on the sample names. However, if the 'chgrp' command fails (for example if the specified group doesn't exists or is inaccessible for the current user), the entire script fails and results will not be imported back into BASE.

Error: [1] chgrp: 
changing group of `/home/thep-nni/../.._L1_R1.fastq.gz': Operation not permitted
...

This is a bit unfortunate since the failure can typically be fixed easily by a superuser on the file server and there is really no need to have to delete and re-run the analysis.

[Nicklas Nordborg]

If we do chgrp .... || true a failure to change the group will not stop the script. Error messages will be written to stderr. We could redirect to a file: chgrp ... 2>> ${WD}/chgrp.out || true. Then it would be possible for Reggie to pick up any problems and maybe issue a warning (${WD} is the working directory for the job that we already use for other data files that we need information from after the job has been completed).

[Nicklas Nordborg]

In 5618:

References #1178: Scripts should not fail if it can't change group on files

The chgrp command has now been exteded to chgrp ... 2>> ${WD}/chgrp.out || echo [<name-of-item] >> ${WD}/chgrp.out

which means that:

• Errors from the chgrp command are written to chgrp.out in the working directory.
• The script doesn't fail if there is an error
• Instead, the echo part is executed which output the name of the item (eg. library, alignment, etc) to the chgrp.out file.

After the job has ended, it should be possible to parse the chgrp.out file and see if there are any errors and then also to which item the error is related. This is not yet implemented.

[Nicklas Nordborg]

In 5619:

References #1178: Scripts should not fail if it can't change group on files

Implemented parsing of the 'chgrp.out' file in the demux result handlers. Information from the file is added to the demux item as warnings and will cause the auto-confirmation to stop processing.

[Nicklas Nordborg]

Since there is no good way to report back warnings from the other steps in the secondsary analysis I think the best options for now is to simply ignore it. Most problems should be catched in the demux step in any case.