<p>To quote from the <a href="https://snakemake.readthedocs.io/en/stable/snakefiles/configuration.html#configure-working-directory" rel="nofollow noreferrer">snakemake documentation</a></p>
<blockquote>
<p>All paths in the snakefile are interpreted relative to the directory snakemake is executed in. This behaviour can be overridden by specifying a workdir in the snakefile:</p>
<p><code>workdir: &quot;path/to/workdir&quot;</code></p>
<p>Usually, it is preferred to only set the working directory via the command line, because above directive limits the portability of Snakemake workflows.</p>
</blockquote>
<p>It's not explicitly stated, but it's sort of implied that all relative paths then become relative to the working directory. I would expect that specifying an absolute path would get around this.</p>
<p>As an aside, in my mind setting the working directory is usually only needed on clusters without a shared file system (presumably shared between the worker nodes, but not with the head node), since there you can't <code>cd $WORKDIR</code> before running snakemake. This is then normally done with your scheduler, in such cases.</p>

CC BY-SA 3.0
2017-07-19T08:24:35.210Z
thx for your answer. I had seen this statement in the doc. I understand that all path in the snakefile are interpreted relative to the workdir (very practical by the way) but I feel it is still strange behavior that an option of the command line is interpreted the same way. Moreover, setting a workdir simplifies a lot the writing of the inputs and outputs (no need to prefix all files with the output dir you want)
Eric C.
CC BY-SA 3.0
2017-07-19T09:54:58.080Z
@EricC. I agree in this case, I would also have preferred that the working dir not apply to paths specified on the command line.
Devon Ryan
CC BY-SA 3.0
2017-07-20T12:28:43.970Z
yes maybe Johannes Köster will one day change this behavior, except if for some reason I don't get, it has other drawbacks.
Eric C.
CC BY-SA 3.0
2017-07-18T18:17:26.237Z
2017-07-18T18:44:51.447Z
2020-06-18T08:30:41.743Z
Devon Ryan
<p>It's just a guess, but I think you might want to use <code>--keep-target-files</code> flag to not to adjust paths of targets. From <a href="http://snakemake.readthedocs.io/en/stable/executable.html?highlight=keep-target-files" rel="nofollow noreferrer">snakemake manual</a> :</p>

<blockquote>
  <p><code>–keep-target-files</code></p>
  
  <p>Do not adjust the paths of given target files relative to the working
  directory.</p>
  
  <p>Default: False</p>
</blockquote>

<p>So if I understand right <a href="https://bioinformatics.stackexchange.com/questions/2090/combining-the-use-of-workdir-and-option-jobscript-in-snakemake/2094#2094">Devon's answer</a>, combination of this flag and setting of <code>workdir</code> could force compute target in different directory that the snakemake is executed in.</p>

CC BY-SA 3.0
2017-11-10T13:40:24.453Z
2017-11-10T13:40:24.453Z
Kamil S Jaron
<p>It seems that in snakemake the script specified after the <code>--jobscript</code> cannot be used properly if a <code>workdir:</code> is specified in the snakefile. 
The path of the script specified becomes relative to the workdir defined in the snakefile instead of being relative to the current working directory. I do not know if this is a feature or a bug !!</p>

<p>Nevertheless, it becomes quite painful to workaround this problem. The only way I found was to parse the command line in the snakefile, for example:
<code>
snakemake -c "qsub" -j 30 --js ./sge.sh --latency-wait 30 -rp
</code>
in order to copy <code>./sge.sh</code> in the output directory defined by the keyword <code>workdir</code> in the snakefile.</p>

<p>As a side effect, if you specify option for qsub on the command line, for example:
<code>
snakemake -c "qsub -e ./logs/ -o ./logs/" -j 30 --js ./sge.sh --latency-wait 30 -rp
</code>
the <code>logs</code> folder must be created under the workdir directory.</p>

<p>Is there something I don't understand with the <code>--jobscript</code> option? Am I not using it the right way? Am I going against the best practice?</p>

<snakemake>
combining the use of workdir and option --jobscript in snakemake
# combining the use of workdir and option --jobscript in snakemake

(Asked by: username_0 on 2017-07-18)

It seems that in snakemake the script specified after the `--jobscript` cannot be used properly if a `workdir:` is specified in the snakefile.
The path of the script specified becomes relative to the workdir defined in the snakefile instead of being relative to the current working directory. I do not know if this is a feature or a bug !!

Nevertheless, it becomes quite painful to workaround this problem. The only way I found was to parse the command line in the snakefile, for example:
`snakemake -c "qsub" -j 30 --js ./sge.sh --latency-wait 30 -rp`
in order to copy `./sge.sh` in the output directory defined by the keyword `workdir` in the snakefile.

As a side effect, if you specify option for qsub on the command line, for example:
`snakemake -c "qsub -e ./logs/ -o ./logs/" -j 30 --js ./sge.sh --latency-wait 30 -rp`
the `logs` folder must be created under the workdir directory.

Is there something I don't understand with the `--jobscript` option? Am I not using it the right way? Am I going against the best practice?

**Tags:** snakemake

---

## 2 answers

### Answer by username_1 on 2017-07-18. Score: 2 | Accepted answer

To quote from the [snakemake documentation](https://snakemake.readthedocs.io/en/stable/snakefiles/configuration.html#configure-working-directory)

> All paths in the snakefile are interpreted relative to the directory snakemake is executed in. This behaviour can be overridden by specifying a workdir in the snakefile:
>
> `workdir: "path/to/workdir"`
>
> Usually, it is preferred to only set the working directory via the command line, because above directive limits the portability of Snakemake workflows.

It's not explicitly stated, but it's sort of implied that all relative paths then become relative to the working directory. I would expect that specifying an absolute path would get around this.

As an aside, in my mind setting the working directory is usually only needed on clusters without a shared file system (presumably shared between the worker nodes, but not with the head node), since there you can't `cd $WORKDIR` before running snakemake. This is then normally done with your scheduler, in such cases.

> **Comments:**
> **username_0**: thx for your answer. I had seen this statement in the doc. I understand that all path in the snakefile are interpreted relative to the workdir (very practical by the way) but I feel it is still strange behavior that an option of the command line is interpreted the same way. Moreover, setting a workdir simplifies a lot the writing of the inputs and outputs (no need to prefix all files with the output dir you want)  
> **username_1**: @EricC. I agree in this case, I would also have preferred that the working dir not apply to paths specified on the command line.  
> **username_0**: yes maybe Johannes Köster will one day change this behavior, except if for some reason I don't get, it has other drawbacks.  

---

### Answer by username_2 on 2017-11-10. Score: 1

It's just a guess, but I think you might want to use `--keep-target-files` flag to not to adjust paths of targets. From [snakemake manual](http://snakemake.readthedocs.io/en/stable/executable.html?highlight=keep-target-files) :

> `–keep-target-files`
>
> Do not adjust the paths of given target files relative to the working
> directory.
>
> Default: False

So if I understand right [Devon's answer](https://bioinformatics.stackexchange.com/questions/2090/combining-the-use-of-workdir-and-option-jobscript-in-snakemake/2094#2094), combination of this flag and setting of `workdir` could force compute target in different directory that the snakemake is executed in.


---

