I'm using the File Should Exist keyword to check for an existing file in a List.
This is the high-level format:
Variables:
#{Files} /Desktop/Other/scooby.txt
... /Desktop/DummyFiles/daffy.txt
... %{CURDIR}/mickey.txt
Test Case:
Given File Should Exist ${Files[0]}
[...]
Output:
Setup failed:
Path '/Desktop/Other/scooby.txt' does not exist.
I'm not sure why this happens. The file name and filepath are correct. I also tried a bunch of different combinations (I copied the file over to the subdirectory this script is running from but that also doesn't work). I tried making the filepath a scalar variable instead of a List/array. Adding ".." in front of the file path doesn't work either. I've looked into "Glob pattern" but I don't think that's the issue either.
Always use absolute paths if in doubt. For example - /Desktop/Other/scooby.txt Does not point to any "meaningful" path even on windows because its lacking the the drive. On windows, using C:/Users/$yourlocalusername/Desktop/Other/scooby.txt might be working (replace $yourlocalusername with correct value)
Relying on relative paths (like in your example, 2 first ones are relative even thought you start with /, because in windows you still have a drive at the start) - you will need to ensure that working directory is set to a specific directory before you run your suite. Now, if you run your suite via IDE, current working directory might not be what you expect it to be so before you are familiar with how relative & absolute paths work - prefer to use absolute paths. See https://www.computerhope.com/issues/ch001708.htm - maybe that will clear out your issue.
You can either use ${CURDIR} or do not start the relative path with '/'.
I guess when starting with '/' , RF does not take this as relative path input and try to map the address from root directory i.e. C:
In below example, I have demonstrated both the approach, and it works fine for me.
*** Settings ***
Library OperatingSystem
Documentation Demonstrating File Exist keywords
*** Variables ***
#{Files} Data/VariableData/ConditionalFlows.robot
... Data/VariableData/testdata.robot
#{Files2} ${CURDIR}/Data/VariableData/ConditionalFlows.robot
... ${CURDIR}/Data/VariableData/testdata.robot
*** Test Cases ***
TS002-Check For File Existence
[Documentation] File exists
${File} File Should Exist ${Files}[0]
${File} File Should Exist ${Files2}[0]
Related
I have set up a certain relative path in one of my scripts. E.g. like below:
starting_dir <- "C:/Users/USER/long folder name 1/long folder name 2/"
setwd(starting_dir)
From this path I want to navigate around a bit to save some files in folder some levels above (and down again), e.g. like:
folder_change <- "../long folder name test/"
file_name <- "very loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong name.txt"
If I glue that together, it would give me the following ABSOLUTE path:
normalizePath(paste0(folder_change, file_name))
"C:\\Users\\USER\\long folder name 1\\long folder name test\\very looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong name.txt"
(Note: it will give you a warning because the file itself does not yet exist, but we can ignore that for now.)
And running nchar() around that path gives me a length of 237 characters, which is still below Windows' limit of 260 characters.
However, if I increase the file name by just one character (note: it might be more or less characters for you depending on how long your USER name in the path is!), then the path would not be a valid Windows path anymore and it would give me a non-working path
file_name <- "very looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong nameX.txt"
normalizePath(paste0(folder_change, file_name))
This would lead to the following output (not how it stops showing the the full beginning of the path):
[1] "../long folder name test/very looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong nameX.txt"
along with a warning file or extension cannot be found.
So specifiying the path in absolute terms works, doing it with relatives paths does not.
The problem is that I run a few function where I glue together a relative path, and these error because the relative path is not valid.
I'm confused about this behaviour, because the actual path is valid and works.
What can I do about it?
I am running a pipeline and was trying to optimize it by declaring the paths in a config file (config.yaml). The config.yaml file contains the path to find the scripts to run inside the pipeline, but when I expand the wildcard of the path, the pipeline does not run the script. The script itself runs fine.
To explain my problem:
rule with_script:
input: someinput
output: someoutput
script: expand("{script_path}/scriptfile", script_path = config[scriptpath])
input, output or rule all do not contain the script's path wildcard, so here is the first time I'm declaring it. The config.yaml line that contains the path looks like this:
scriptpath: /path/to/the/script
is there a way to maintain the wildcard and config file path (to make it easier for others to make changes if needed) and have the script work? Like this snakemake doesn't even enter the script file. Or maybe it is possible to declare global wildcards outside the rule all?
Thank you for your help!
P.S.: I'm sorry if this question has already been answered, but I couldn't find anything to help me with this.
You cannot define a function like expand() in the script section. Snakemake expects a path to your script.
Like the documentation states:
The script path is always relative to the Snakefile containing the directive (in contrast to the input and output file paths, which are relative to the working directory). It is recommended to put all scripts into a subfolder "scripts"
If you need to define different paths to your scripts, you can always do it in python outside of your rules. Don't forget, all python code outside of rules is executed before building the DAG. Thus, you can define all variables you want and use them in your rules.
SCRIPTSPATH = config["scriptpath"]
rule with_script:
input: someinput
output: someoutput
script: "{SCRIPTSPATH}/scriptfile"
Note:
Do not mix wildcards and "variables". In an expand function as
expand("{script_path}/scriptfile", script_path = config[scriptpath])
{script_path} is not a wildcard but just a placeholder for the values given in the second parameter of the function.
In Julia, I can get the current directory from
#__DIR__
For example, when I run the above in the "Current" folder, it gives me
"/Users/jtheath/Dropbox/Research/Projects/Coding/Current"
However, I want it to return one folder above the present folder; i.e.,
"/Users/jtheath/Dropbox/Research/Projects/Coding"
Is there an easy way to do this in a Julia script?
First, please note that #__DIR__ generally expands to the directory of the current source file (it does however return the current working directory if there are no source files involved, e.g when run from the REPL). In order to reliably get the current working directory, you should rather use pwd().
Now to your real question: I think the easiest way to get the path to the parent directory would be to simply use dirname:
julia> dirname("/Users/jtheath/Dropbox/Research/Projects/Coding/Current")
"/Users/jtheath/Dropbox/Research/Projects/Coding"
Note that AFAIU this only uses string manipulations, and does not care whether the paths involved actually exist in the filesystem (which is why the example above works on my system although I do not have the same filesystem structure as you). dirname is also relatively sensitive to the presence/absence of a trailing slash (which shouldn't be a problem if you feed it something that comes directly from pwd() or #__DIR__).
I sometimes also use something like this, in the hope that it might be more robust when I want to work with paths that actually exist in the filesystem:
julia> curdir = pwd()
"/home/francois"
julia> abspath(joinpath(curdir, ".."))
"/home/"
What does ..\ at the start of a file path do?
Example: The following file is referenced in the directory
\work\QA\Reports\TimeOff.rpt
What is the difference between referencing the file path as \work\QA\Reports\TimeOff.rpt and referencing the file path as ..\work\QA\Reports\TimeOff.rpt?
it's the difference between relative and absolute path referencing.
\work\QA\Reports\TimeOff.rpt
starts with a (back)slash "\" (or "/" in unix if it matters), so it's indicating "Start at the root, or top most level directory".
Then navigate down.
It's an Absolute path reference. It doesn't matter where you are, you will always end up pointing to the same file/location.
.\work\QA\Reports\TimeOff.rpt
however, begins with "." Which is Relative path reference. It says to "start where you currently are". so if you were already in folder: \my\home\directory
then you'll end up navigating to:
\my\home\directory\work\QA\Reports\TimeOff.rpt
".." is a reference to go one level up ... but again "relative path".
so:
..\work\QA\Reports\TimeOff.rpt
if you were in \my\home\directory
you'd end up here:
\my\home\work\QA\Reports\TimeOff.rpt
Since it backs up one level ("\directory\") ..and goes from there.
Hope that makes sense ;)
.. refers to the parent directory, the directory one level up from the current directory. Additionally, . refers to the current directory.
Say you're in directory \a\b\c\. You want to access file \a\b\c\d. You can access that file with just d or .\d or \a\b\c\d. Say you now want file \a\b\x. You can access that as ..\x or the full absolute path. You can, of course, chain . and .., like ..\.\..\y.
Paths starting with \ are absolute (or <drive letter>:\); they refer to the same file every time and don't depend on the current directory. Other paths are relative, the file they refer to changes with the current directory.
It means go to parent folder first and then look for the path specified.
so it is basically the same when you do cd .. in command line.
The difference between \work\QA\Reports\TimeOff.rpt and ..\work\QA\Reports\TimeOff.rpt is thet if you're in \a\b folder, first one will match \a\b\work\QA\Reports\TimeOff.rpt and second one a\work\QA\Reports\TimeOff.rpt.
I am using the following code to try and find a file contained in another directory from my code file.
Set fi=fs.OpenTextFile(Server.MapPath("~/counter/counter.txt"), 1)
I have also tried.
Set fi=fs.OpenTextFile(Server.MapPath("./root/folder1/counter/counter.txt"), 1)
In either case this should get me back to the counter.txt file. From what I understand ~/ moves up 1 directory and ./ moves up to the root directory.
Both times however I receive an error saying an invalid character has been used. When removing these I get a different error saying the path cannot be found (Which I would expect because it is not a valid path without moving up 1 directory).
What are the valid characters to do the following in VBscript:
move up a single directory?
move up to the root directory?
Thanks for the help
A few things:
The tilde character "~" is not valid here.
The single period character "." is for specifying the current directory/folder.
A set of period characters ".." is for specifying the parent directory/folder. For example, to refer to a file found in the parent of the current directory, you might use:
Server.MapPath("../counter.txt")
You can chain these to walk up more than a single parent path. To refer to a file found three directories above the current, you might use:
Server.MapPath("../../../counter.txt")
The documentation on MSDN for the MapPath function outlines this. Pay attention to the caution listed here about enabling parent paths if you want to be able to refer to relative paths above the current directory. If you get an error when trying to refer to a parent path, then you do not have parent paths enabled.