combining the use of workdir and option --jobscript in snakemake 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?
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: &quot;path/to/workdir&quot;
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.