text: user373: 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?
  
  user57: 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 :
  
  –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, combination of this flag and setting of workdir could force compute target in different directory that the snakemake is executed in.
  
  user77: To quote from the snakemake documentation
  
  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.
  
original_text: 373: <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>
   57: <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>
   77: <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>
  